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Abstract 

A concurrent system consists of processes and shared objects. Previous research 
focused on the problem of tolerating process failures. We study the complementary 
problem of tolerating object failures. 

We divide object failures into two broad classes: responsive and non-responsive. 

With responsive failures, a faulty object responds to every invocation, but responses 
may be incorrect. With non-responsive failures, a faulty object may also “hang” without 
responding. For each class, we consider crash, omission , and arbitrary types of failures. 

For each type of failure, we are seeking a universal implementation for fault- tolerant 
wait-free shared objects. We present (deterministic) implementations for all types of 
responsive failures, including arbitrary failures. In contrast, we show that even the most 
benign type of non-responsive failures requires the use of randomization. 

Of special interest is the problem of implementing fault-tolerant objects using only 
objects of the same type. We present such fault- tolerant ^//-implementations for many 
common object types. 

Graceful degradation is a desirable property of fault- tolerant implementations: the 
implemented object never fails more severely than the base objects it is derived from, 
even if all the base objects fail. For several failure models, we show whether this 
property can be achieved, and, if so, how. 

In addition to the above possibility/ impossibility results, we also consider the re- 
source complexity of fault- tolerant implementations. In many cases, we present lower 
bounds and give matching algorithms. 

* A preliminary version of this will appear in the proceedings of the 33rd Annual Symposium on Founda- 
tions of Computer Science, October, 1992. 

f Research supported by NSF grants CCR-8901780 and CCR-9102231, DARPA/NASA Ames grant NAG- 
2-593, grants from the IBM Endicott Programming Laboratory. 

*Also supported by an IBM graduate fellowship. 
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Introduction 


1.1 Background and motivation 

A concurrent system consists of processes communicating via shared objects. Examples 
of shared object types include data structures such as read/write register, queue, and 
set, and synchronization primitives such as test&set, fetch&add, and compare&swap. 
Even though different processes may concurrently access a shared object, the object must 
behave as if ail these accesses occur in some sequential order. More precisely, the behavior 
of a shared object must be linearizable [HW90]. One way to ensure linearizability is to 
implement shared objects using critical sections [CHP71]. This approach, however, is not 
fault-tolerant: The crash of a process while in the critical section of a shared object can 
permanently prevent the rest of the processes from accessing that object. This lack of fault- 
tolerance led to the concept of wait- free implementations of shared objects. Informally, a 
shared object is wait-free if every operation invocation on that object by every process is 
guaranteed a response in finite time irrespective of the speed of the other processes, even if 
some or all other processes in the system crash. 

Thus, a concurrent system in which all shared objects are wait-free is resilient to pro- 
cess crashes. However, such a system is not resilient to the failures of the shared objects 
themselves. 1 For example, the “crash” of a single shared object stops all the processes that 
need to access that object. Motivated by this observation, we study the problem of imple- 
menting wait-free shared objects that are also fault-tolerant . With such objects, the system 
is guaranteed to make progress despite process crashes and the failures of some underlying 
objects. (To simplify notation, hereafter “object” denotes a “shared object”.) 

The problem addressed in this paper is novel. A preliminary version appeared in 
[JCT92a], and a summary of the results in [JCT92b]. An independent work by Afek, 
Greenberg, Merritt, and Taubenfeld [AGMT92] has the same general goal, but differs in 
many respects. We present a brief comparison of the two works in Section 8. 

1.2 Object failures 

We divide object failures into two broad classes: responsive and non-responsive. With 
responsive failures, a faulty object responds to every invocation, but responses may be in- 
correct. With non-responsive failures, a faulty object may also “hang” without responding. 

We divide responsive failures into three models: R-crash , R-omission , and R-arbitrary. 
An object that fails by R-crash behaves correctly until it fails, and once it fails, it returns 
a distinguished response _L to every operation. As with R-crash, an object that fails by 
R-omission may return a correct response or a _L. However, even if it responds 1 to a 
process p, a subsequent operation by a different process q may get a correct response. 
This behavior models an object O made of severed components, some of which failed. The 

1 Even “software” objects have underlying hardware components. The software and/or the hardware 
could be faulty. 
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operation by p “ran into” a failed component of O (and returned J_), while the later one 
by q only encountered correct components of O (and returned a correct response). Finally, 
objects experiencing R-arbitrary failures may “lie”, i.e., return arbitrary responses. 

Similarly, we divide non-responsive failures into crash, omission, and arbitrary. An 
object that fails by crash behaves correctly until it fails, and once it fails, it stops responding. 
An object that fails by omission may fail to respond to the invocations of an arbitrary subset 
of processes, but continue to respond to the invocations of the remaining processes (forever). 
The behavior of an object that experiences an arbitrary failure is completely unrestricted: 
it may not respond, and even if it does, the response may be arbitrary. 


1.3 Fault-tolerant objects 

Let T be an object type and C = (7\, T 2 , . . . , T n ) be a list of object types (T* ’s are not neces- 
sarily distinct). A wait-free implementation of T from £ is a function I such that given any 
distinct objects Oi,0 2 , ... ,O n of type Ti,T 2 , . . . ,T n , respectively, O = l(Oi,0 2 , . . . ,O n ) is 
an object of type T that behaves correctly if all 0;’s behave correctly. Roughly speaking, an 
object behaves correctly if it is wait-free and its behavior is consistent with its type. We say 
O is a derived object of the implementation J, and 0i,0 2 , . . . ,O n are the base objects of O. 
The resource complexity of X is n, the number of base objects required by X to implement 
a derived object. Such a wait-free implementation X is t-tolerant for failure model M if O 
behaves correctly even if at most t base objects of O fail by M. In this Introduction, we 
write “implementation” as a shorthand for “wait-free implementation”. 

J is a self -implementation if = T 2 = . . . = T n = T. In other words, in a self- 
implementation the base objects are of the same type as the derived object. For example, 
consider the object type “2-process queue” (i.e., a queue that can be accessed by at most 
two processes). In Section 5.3, we show that there is a t-tolerant self- implementation of 
2-process queue for R-arbitrary failures. Intuitively, this means that using a set of wait-free 
2-process queues, at most t of which may experience R-arbitrary failures, one can implement 
a failure- free wait-free 2-process queue. Thus in a self-implementation fault- tolerance is 
achieved through replication. 

1.4 Results 

To study whether a general object type has a t-tolerant implementation, we focus on two 
particular object types: consensus 2 and register. Herlihy [Her91] and Plotkin [Plo89] 
showed that one can implement a wait-free object of any type (for which a sequential im- 
plementation exists) using only consensus and register objects. Thus, if consensus and 
register have t-tolerant implementations, then every object type has a t-tolerant imple- 
mentation. 

2 A consensus object supports two operations propose 0 and propose 1, and has the following sequential 
specification: If the first operation on the object is propose v (v € {0,1}), then every operation is returned 
the response v. 
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We first study the problem of tolerating responsive failures. We give t-tolerant self- 
implementations of consensus for R-crash, R-omission, and R-arbitrary failures. For 
R-crash and R-omission failures, our self- implementation is optimal requiring only t + 1 
base consensus objects. For R-arbitrary failures, our self-implementation is efficient re- 
quiring O(tlogt) base consensus objects. We also give t-tolerant self-implementations of 
register for R-crash, R-omission, and R-arbitrary failures. Combining the above results 
with [Her91, Plo89], we conclude that every object type T has a t-tolerant implementa- 
tion (from consensus and register) for all responsive models of failures. Moreover, if T 
implements consensus and register, then T has a t-tolerant ^//-implementation. This 
implies that familiar object types such as (2-process) fetch&add, queue, stack, test&set, 
and (N-process) compare&swap, move, swap have t-tolerant self-implementations even for 
R-arbitrary failures! 

What about tolerating non-responsive failures? We first show that there is no 1- 
tolerant implementation of consensus even for crash failures, the most benign of the non- 
responsive models of failures. 3 This immediately implies that any object type T that imple- 
ments consensus such as fetch&add, queue, stack, test&set, compare&swap, move, 
sticky-bit, swap, has no 1-tolerant implementation for crash failures. In contrast, we 
show that register has a t-tolerant ^//-implementation even for arbitrary failures. Since 
randomized implementations of consensus from register are well known (for example, 
see [Asp90]), the above result implies that every object type has a randomized t-tolerant 
implementation from register even for arbitrary failures. In addition to these universality 
and impossibility results, this paper contains the following results. 

Consider a t-tolerant implementation for failure model M. By definition, a derived 
object of this implementation is guaranteed to behave correctly even if up to t base objects 
fail by M . . But what happens if more than t base objects fail? In general, the derived 
object may experience a more severe failure than M.. In other words, implementations 
may “amplify” failures: derived objects may fail more severely than base objects. This 
undesirable behavior is prevented by implementations that are “gracefully degrading” . An 
implementation is gracefully degrading for failure model M if it has the following property: 
if base objects only fail by A4, then derived objects also fail by M. 

From a 1-tolerant gracefully degrading self-implementation of any object type T for a 
failure model Af , we show how to recursively construct a t-tolerant gracefully degrading self- 
implementation of T for M. Thus, graceful degradation provides a method for automatically 
increasing the fault-tolerance of an implementation. 

Requiring graceful degradation may increase the cost of an implementation. For in- 
stance, consider t-tolerant implementations of consensus for R-omission failures. We 
present two such implementations. One uses only t + 1 base objects, but is not grace- 
fully degrading. The other is gracefully degrading, but requires 2t + 1 base objects. In 
fact, we show that graceful degradation for R-omission failures requires at lefts t 2t -1- 1 base 

3 The impossibility of implementing a fault- tolerant consensus object from any finite list of base objects, 
one of which may crash, is shown using the impossibility of solving the consensus problem among a finite 
number of processes , one of which may crash [FLP85, LAA87]. 
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objects (this lower bound holds for every deterministic non-trivia! type). 

In some cases, graceful degradation cannot be even achieved. In particular, we show 
that there is a large class of object types that have no gracefully degrading implementations 
for R-crash. Intuitively, this means that whatever the implementation, the failure of the 
implemented object will be more severe than R-crash, even if all its base objects can only 
fail by R-crash. In other words, with R-crash, implementations necessarily amplify failures. 
In contrast, we prove the following strong possibility result for R-omission: Every object 
type has a t-tolerant gracefully degrading implementation from consensus and register 
for R-omission. 

We study the problem of translating severe failures into more benign failures [NT90]. 
In particular we show that given 3t + 1 (base) consensus objects, at most t of which may 
experience R- arbitrary failures, we can implement a consensus object that can only fail 
by R-omission. We prove that this translation from R-arbitrary to R-omission is resource 
optimal. 

We also show that arbitrary failures can be viewed as having two orthogonal compo- 
nents: omission and R-arbitrary. Specifically, for any object type T, given any t-tolerant 
self-implementations I' and l ,f of T for omission failures and R-arbitrary failures respec- 
tively, we show how to construct a t-tolerant self-implementation of T for arbitrary failures. 
This decomposition simplifies the problem of tolerating arbitrary failures. 

The paper is organized as follows. We give an informal system model and define several 
types of object failures in Sections 2 and 3. We define the concepts of t-tolerant wait-free 
implementation and graceful degradation in Section 4. We provide a formal presentation of 
the material of Sections 2, 3, and 4 in Appendices A, B, and C, respectively. In Section 5, 
we show how to implement objects that tolerate responsive failures. We present t-tolerant 
implementations of consensus in Section 5.1, of register in Section 5.2, and of arbitrary 
types in Section 5.3. The results on the cost of graceful degradation, and on the translation 
between failure models are also presented in Section 5.1. In Section 6, we study the fea- 
sibility of fault -tolerant implementations for non-responsive object failures. We first prove 
that many common object types including consensus have no 1-tolerant implementations 
for crash. In contrast, we show that register has a t-tolerant self-implementation even 
for arbitrary failures. We finally show that every object type has a t-tolerant randomized 
implementation from register even for arbitrary failures. In Section 7, we study graceful 
degradation for the R-crash and R-omission failure models. We present impossibility re- 
sults for R-crash and a universality result for R-omission. In Section 8, we present a brief 
comparison with the results in [AGMT92]. In Appendix D, we define the object types that 
appear in this paper. 


2 Informal model 

A concurrent system consists of processes and shared objects. Associated with each object 
is a type. The type characterizes the expected behavior of the object. More precisely, an 
object type T is a tuple ( N , OP, RES , G) , where N is an integer greater than one, OP and 
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RES are sets of operations and responses respectively, and G is a directed finite or infinite 
graph in which each edge has a label of the form (op, res) where op £ OP and res £ RES. 
Intuitively, if O is an object of type T, then O supports the operations in OP and may be 
shared by N processes (we say T is an N -process type), G specifies the expected behavior 
of O in the absence of concurrent operations on O, 

The vertices of G are the states ofT. One state of T is the initial state. A state s of 
T is reachable if there is a path in G from the initial state to s. We assume that every state 
of T is reachable. A sequence 5 =(opi, resi),(op2,re$2)> - - ">(opi, T esi) is consistent from a 
state s ofT if there is a path labeled S in G from the state s. S is consistent with respect 
to T if it is consistent from the initial state of T. T is deterministic if for every state s of 
T and every operation op £ OP, there is at most one edge from s labeled (op, res). T is 
non- deterministic otherwise. T is finite if G is finite; T is infinite otherwise. 

An object G of type T supports the set of procedures Apply (P, op,(9), for each pro- 
cess P and operation op in OP(T). A process P invokes operation op on object O by 
calling Apply (P, op, O), and executes the operation by executing this procedure. The oper- 
ation completes when the procedure terminates. The response for an operation is the value 
returned by the procedure. 

The sequential specification of an object (9, given by its type, is not sufficient to predict 
CPs behavior in the presence of concurrent operations. To characterize such behavior, we 
use the concept of linearizability [HW90, Lam86]. Roughly speaking, line ariz ability requires 
every operation execution to appear to take effect instantaneously at some point in time 
between its invocation and response. We make it more precise below. 

An execution of a concurrent system is an interleaving of the steps of the processes 
and the invocations and responses of the objects. Consider an execution E of a concurrent 
system consisting of an object O that is shared by processes Pi, P 2 , . . . , P/y. The history 
7i of O in E is a set defined as follows: (Pj,op, £ H iff in execution E, process 

Pi invokes op at time and this operation completes at time t e returning the response 
v . Further, (Pj, op, *, t s , 00 ) £ Ti, iff process Pi invokes op at time t 3 , and this operation 
does not complete. A history is complete if it has no incomplete operations. Given two 
operations (P^, op, u, t 3 , t € ) and (Pj, op', t/, ) in a history, we say (Pi,op,v,t s ,t e ) precedes 

{P h <yp\v ' if t e < t'. A complete history H is linearizable with respect to a type T if 
there is a sequencing S of the tuples (operations) in H such that S respects the ‘precedes’ 
relation, and is consistent with respect to T. A history H is linearizable with respect to 
a type T if a linearizable complete history H! can be obtained from H as follows: each 
incomplete operation (P^,op,*,t 3 , 00 ) in Ti is either removed or replaced by a complete 
operation (P*,op, i>,tj,t c ), for some response v and time t e . This definition captures the 
notion that some incomplete operations in 7i had a “visible” effect, while the others did 
not. 

Processes are asynchronous: t.e., there axe no bounds on the relative speeds of the 
processes. Furthermore, a process may crash : i.e., a process may stop at an arbitrary point 
in an execution and never take any steps thereafter. The concept of wait-freedom was 
introduced to cope with such processes (for example, see [Her91]). An object O is wait-free 
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in an execution E if either (i) E is finite, or (ii) every operation on O invoked by a process 
that does not crash in E gets a response from O . 

An object O is correct in execution E iff (i) O is wait-free in E , and (ii) the history of 
O in E is linearizable with respect to the type of O. We say that O fails in E iff O is not 
correct in E. Even a faulty object may satisfy certain properties which depend on the type 
of failure it suffered. We postpone the definition of the failure models to next section. 

Let T be an object type and C = (Ti,T 2 , . . . ,T n ) be a list of object types (TVs 
are not necessarily distinct). A wait- free implementation of T from C is a function 2 
such that given any distinct objects 0i,0 2 ,...,0 n of type Ti, T 2 , . . . , 2 n , respectively, 
O = J(0i, 0 2 , • • • 1 0 n ) is an object of type T with the following property: In every ex- 
ecution, if 0i, 0 2 , . . . , O n are correct, then O is correct. We say 0 is a derived object of 
the implementation 2, and 0i,0 2 , . . . ,0 n are the base objects of O. All implementations 
studied in this paper are wait-free. Hereafter we write “implementation” as shorthand for 
“wait-free implementation” . 

We define the terms self -implementation of T and resource complexity as in Section 
1.3. Our interest lies not just in implementations, but in implementations that tolerate the 
failures of base objects. Thus, we also need to define a fault-tolerant implementation. We 
present such a definition in Section 4, after defining failure models in Section 3. 


3 Failure models 

An object is only an abstraction with a multitude of possible implementations. For in- 
stance, it may be built as a hardware module in a tightly coupled multi-processor system, 
or as a server machine in a message passing distributed system. Whatever the implementa- 
tion, the reality is that hardware components sometimes fail, and when this happens, the 
implementation fails to provide the intended abstraction. 

Object failures lead to undesirable system behavior. Therefore, it is important to 
implement derived objects that behave correctly even if some of the base objects of the 
implementation fail. The complexity of such a fault-tolerant implementation depends on the 
failure model , i.e., the manner in which a failed base object departs from correct behavior. 
In this paper, we define a spectrum of failure models that fall into two broad classes: 
responsive and non-responsive. 

As we will see, in most models of failure, an object O of type T may fail by returning a 
response that is not allowed by its type; that is, a response not in RES(T). When a process 
P gets such a response from <9, it knows that O is faulty. Thus, it is reasonable to ass um e 
that P does not invoke operations on O thereafter. We restrict our attention to executions 
in which this assumption holds. 
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3.1 Responsive models of failure 


An object experiencing a responsive failure responds to every invocation, even though the 
response may be incorrect. In other words, the object remains wait-free even after if it fails. 
We describe below three increasingly severe models of responsive failures. 

3.1.1 R-crash 

R-crash is the most benign model of object failure. Informally, an object that fails by R- 
crash behaves correctly until it fails, and once it fails, it returns a distinguished response 
JL to every invocation. This model is based on the premise that an object detects when it 
becomes faulty. 

More precisely, an object 0 fails in execution E by R-crash iff it fails in E y and satisfies 
the following properties: 

1. 0 is wait-free in E. 

2. Every response from 0 in E is either A. or one of the responses allowed by the type 
of 0 . An operation that returns ± is an aborted operation. 

3. Let 7i be the history of 0 in E . Every operation in H that is preceded by an aborted 
operation is itself an aborted operation. 

4. Removing the aborted operations from Ti results in a linearizable history with respect 
to the type of 0. 

Property 3 is the “once JL, everafter JL” property of R-crash. Property 4 models the re- 
quirement that 0 should behave correctly until it fails. 

3.1.2 R-omission 

Consider an implementation X, and a derived object 0 of 1 . Even if the base objects of 0 
can only fail by R-crash, 0 itself may experience a more severe failure than R-crash. To see 
this, suppose a base object b of 0 fails by R-crash. Consider a process P that invokes an 
operation op on 0 and executes Apply (P, op, 0). If Apply(P, op, 0) accesses 6, b returns _L 
to P. This may cause P’s invocation of op on 0 to terminate and return _L. Now suppose 
that another process Q later invokes some operation op f on 0, and that Apply(Q, op', 0) is 
not required to access b. Then, process Q cannot notice the failure of 6. So Q’s invocation of 
op on 0 terminates “normally” and returns a non-1. response. Thus, 0’s behavior violates 
the “once _L, everafter J_” property of R-crash. Does this mean that 0’s failure is arbitrary? 
We now argue that this is not the case. 

Recall that after P gets _L, P refrains from accessing 0 again. To Q , this scenario 
is indistinguishable from one in which P had crashed in the middle of the procedure 
Apply (P, op, 0), while accessing b. Since the implementation I (from which 0 is derived) 
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is wait-free, O tolerates the apparent crash of P. Thus, O’s response to Q must be correct. 
So, the failure of O is more severe than R-crash, but is not completely arbitrary. The 
R-omission model captures such a failure 4 . 

More precisely, an object O fails in execution E by R-omission iff it fails in E , and 
satisfies the following properties: 

1. O is wait-free in E . 

2. Every response from O in E is either _L or one of the responses allowed by the type 
of O. 

3. Let H be the history of O in P. Replacing every aborted operation (P, op, ±, t s , t e ) 
in 7i by an incomplete operation (P, op, *, t s> oo) results in a linearizable history with 
respect to the type of O. 

8' 1.3 R-arbitrary 

An object O fails in execution E by R-arbitrary* iff it fails in E and is wait-free in P. In 
other words, O responds to every invocation in P, but the history of O is not linearizable 
with respect to the type of O. 

3.2 Non-responsive models of failure 

Each responsive model of failure has its non-responsive counter-part. The difference lies in 
the fact that an object experiencing a non-responsive failure may also fail to respond to 
invocations. 

3.2.1 Crash 

Crash is the most benign of all non-responsive models of failure. Informally, an object 
subject to a crash failure behaves correctly until it fails (Property 1, below), and once it 
fails, it never responds to any invocations (Property 2, below). More precisely, an object O 
fails in execution E by crash iff it fails in P, and satisfies the following properties: 

1. The history of O in P is linearizable with respect to the type of O. 

2. The total number of responses from O in P is finite. 

4 Formal justification for the R-omission model will be apparent in Section 7. 

5 For readability, we sometimes prefer writing u O experiences an R-arbitrary failure in E ” . 
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3.2.2 Omission 


Omission failures are more severe than crash. An object O fails in execution E by omission 
iff it fails in E , and the history of O in E is linearizable with respect to the type of O , In 
particular, an object that fails by omission does not necessarily satisfy Property 2 of crash 
model. Thus, an object that fails by omission may not respond to invocations from some 
processes, but respond to invocations from others forever. 

3.2.3 Arbitrary 

The behavior of an object that experiences an arbitrary failure is completely unrestricted. 
In particular, such an object may not respond to an invocation; even if it does, the response 
may be arbitrary. More precisely, an object O fails in execution E by arbitrary iff it fails 
in E . 


4 Definition of fault- tolerant implementations 

An implementation I of type T is t -tolerant for failure model Ad if every derived object O 
oiX has the following property: In every execution, if at most t base objects fail, and they 
fail by Ad, then O is correct. 

An implementation X is gracefully degrading for failure model Ad if every derived object 
O oil has the following property: In every execution, if all base objects that fail, fail by 
Ad, then either O is correct or it fails by Ad. 

Let O be a derived object of an implementation which is both t-tolerant and gracefully 
degrading for failure model Ad. The above definitions imply that: (i) if at most t base 
objects of O fail, and they fail by Ad, then O does not fail, and (ii) if more than t base 
objects of O fail, and they fail by Ad, then O may fail, but it does not experience a more 
severe failure than Ad. Property (i) is guaranteed by t- tolerance, and property (ii) by 
graceful degradation. 

Gracefully degrading implementations can be easily composed as shown in the following 
lemma. Given a list L of integers and an integer n, let MinSum(n,L) be the sum of the n 
smallest integers in L. 

Lemma 4.1 If a type T has a t-tolerant gracefully degrading implementation 1 from the 
list Ti,T 2 , . . . ,T n of types for failure model Ad, and each T{ (1 < i < n) has a ti-tolerant 
gracefully degrading implementation from Tii, Tj2, . . . , Tin for M, then T has a t' -tolerant 
gracefully degrading implementation X' from In, T12, . . . , Ty, , T21, . . . , T 2 j 2 , . . . , T n \, . . . , T n j n 
for M.. In the above, t' = MinSum(t + 1, {<1 + 1, <2 + + 1)) _ 1. 

Proof (sketch) Define I'(on , . . . ,0^,, . . . ,o„i, . . . ,o„ Jn ) = I(Oi,...,O n ) where 0 \ = 
Ti(ou,oi2, • • • , Oij, ), . • • , On = Tn(o n i, o n 2 , o njn ). Assume that each o k i, if it fails, only 
fails by .M . Since I : is ti-tolerant, O, fails only if at least t, + 1 objects among o; 1, . . . , o\j ; 
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fail; furthermore, since X{ is gracefully degrading, 0{ fails only by Ad. S imil arly, since X is 
t-tolerant, T(Oi, . . . , O n ) fails only if at least t + 1 objects among Oi, . . . , O n fail. Thus, 
for T(Oi , . . . , O n ) to fail, at least MinSum(t + 1, (ti + 1, ^ + 1, • . * ,t n + 1)) objects among 
on, . . . , o\j 1 , . . . , o n iy * • * , must fail. In other words, X 7 is a t'-tolerant implementation 
of T from Tn, . . . T n j n . l f is gracefully degrading for Ad because X and each X x (1 < i < n) 
are gracefully degrading for At. □ 

The above lemma can be used to enhance the fault- tolerance of a self-implementation. 
This is the substance of the next corollary, obtained by setting T{ = T, t{ = t, ji — n, and 
Xi = X in the lemma. 

Corollary 4.1 If a type T has a t-tolerant gracefully degrading self-implementation X of 
resource complexity n for a failure model M , then T has a (t 2 + 2t) -tolerant gracefully 
degrading self-implementation X f of resource complexity n 2 for At. 

Recursive application of the above corollary boosts the fault-tolerance of self-implementations. 

Corollary 4.2 (Booster Lemma) If a type T has a 1-fo/eran* gracefully degrading self- 
implementation of resource complexity k for a failure model At, then T has a t-tolerant 
gracefully degrading self-implementation of resource Complexity 0(t log2 ^) for Ad. 

In Section 5.1.4, we illustrate how this corollary can be applied to construct a t-tolerant 
self-implementation of consensus for R- arbitrary failures. 


5 Tolerating responsive failures 

Herlihy [Her91] and Plotkin [Plo89] showed that one can implement a (wait-free) object of 
any type using only consensus find register objects. Therefore, if consensus and register 
have t-tolerant implementations, then every object type has a t-tolerant implementation. 
Hence we focus on fault-tolerant implementations of consensus and register. 

5.1 Fault-tolerant implementation of consensus 

In the following, we first define the object type N-consensus. We then present a t-tolerant 
self-implementation of N-consensus that works for both R-crash and R-omission failures. 
This implementation requires t + 1 base W-consensus objects, and is thus resource opti- 
mal. Following that, we show how to translate R-arbitrary failures of iV-consensus objects 
to R-omission failures. Our translation is also proved’ to be resource optimal. Although 
the above two results can be chained together to obtain a t-tolerant self-implementation of 
N-consensus for R-arbitrary failures, the resultant self-implementation is not resource effi- 
cient: it requires 0(f 2 ) base consensus objects. We therefore present an alternative efficient 
self-implementation of resource complexity 0(t log t). 
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5.1.1 The object type N-consensus 


N-consensus is an iV-process object type that supports two operations, propose 0 and 
propose 1 , and has the following sequential specification: If the first operation invoked 
is propose v, then every invocation (including the first) is returned the response v. The 
following two propositions follow directly from definitions: 

Proposition 5.1 An N-consensus object O is correct in execution E if and only if it is 
wait- free and satisfies the following three properties in E: 

• Validity: If O returns a response v, and v E {0, 1}, then there was a prior invocation 
of propose v on O. 

• Agreement: If O returns V\,V 2 to two invocations, and vi,V 2 € {0, 1}, then iq = ^ 2 . 

• Integrity: Every response of O is either 0 or 1. 

An JV-consensus object O satisfies weak integrity in an execution in E iff every response of 
O in E is either 0, 1, or X. 

Proposition 5.2 Let O be an N-consensus object that fails in execution E. Object O fails 
by R-omission in E if and only if it is wait-free , and satisfies validity, agreement, and weak 
integrity in E. 

In describing our implementations, we write loc := Propose(p,v, O) 6 to denote that 
process p invokes propose v on O and stores the response in its local variable loc . 


5.1.2 Tolerating R- crash and R-omission failures 

We present a t-tolerant self-implementation of N-consensus for R-omission failures. The 
resource complexity is t + 1, and is therefore optimal. Since R-omission failures are strictly 
more severe than R-crash, this self-implementation also works for R-crash. However, it is 
not gracefully degrading either for R-crash or for R-omission. In fact, we will see in Section 
7 that N-consensus has no t-tolerant gracefully degrading implementation for R-crash. For 
R-omission, however, we present a t-tolerant gracefully degrading self-implementation of 
resource complexity 2t + 1. We also prove that 2t + 1 is a lower bound on the resource 
complexity. In fact, this lower bound applies to every “non-trivial” deterministic object 
type, not just to N-consensus; furthermore, it is not restricted to self-implementations. 

Theorem 5.1 Figure 1 gives at-tolerant self -implementation of N-consensus for R-omission 
failures . The resource complexity of the implementation is t + 1 and is optimal. 

^Throughout this paper, we write Propose (with upper case W P W ) if the operation is on a derived object, 
and propose (with lower case “p”) if it is on a base object. 
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01,02, • • • >0t+i * N-consensus objects 

Procedure Propose^, v p , O) /* v p 6 {0,1} */ 
estimate pi w,k : integer local to p 
begin 

estimatep := v p 
for fc := 1 to t + 1 do 

u; := propose(p, estimate p , Ok) 
if w ^ ± then estimate p := w 
return( estimate p ) 


Figure 1: t-tolerant self-implementation of N-consensus for R-omission 


Proof Let O be a derived N-consensus object of the implementation, and Oi, 02? • . . , 0 *+ \ 
be its base objects. Consider an execution E in which at most t base objects fail by R- 
omission, and the remaining objects are correct. We show that O is correct in E. 

1. O satisfies validity : An easy induction on k shows that if estimate p equals some value 
u at any point in E , then there was a prior invocation (from some process q) of 
Propose^, u, O). The induction will use Proposition 5.2, and the fact that p does 
not change estimate p if a base object returns J_. 

2. O satisfies agreement : Since at most t base objects fail, there is an Ok (1 < k < t + 1) 
that is correct. So Ok returns the same response w € {0,1} to every process that 
accesses it. This implies that for all p that access O*, e$timate p = w whenp completes 
the k th iteration of the loop. Since each base object in Ojt+i, . . . , 0*+i is either correct 
or fails by R-omission in J5 1 , by Propositions 5.1 and 5.2, each of these base objects 
satisfies validity. From these facts, it is easy to conclude from the implementation that 
estimatep never changes value from the (k + l)st iteration onwards. Thus O returns 
the same response w to every p. 

3. O satisfies integrity : Obvious. 

Since a base object that fails by R-omission remains wait-free, it is clear that O is wait-free 
in E. By Proposition 5.1, O is correct in E . It is obvious that the resource complexity of 
t + 1 of our self- implementation is optimal. □ 

The above (self) implementation is not gracefully degrading. For instance, suppose that 

= 0 and v q = 1, and all the t + 1 base objects fail by R-crash initially. It is easy 
to see that O returns 0 to p and 1 to q. Thus O does not satisfy agreement, and by 
Proposition 5.2, the failure of O is more severe than R-omission. In fact, we will now show 
that 2t 4- 1 is both a lower and upper bound on the resource complexity of a t-tolerant 
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gracefully degrading self-implementation of N- consensus for R-omission 7 . The gracefully 
degrading self-implementation that requires 2t + 1 base objects is given in Figure 2. 


01,02, * ♦ * ^ 02t+i : N-consensus objects 


Procedure Propose(p, v p , 0) /* v p € {0,1} */ 

V p [l..2t + 1], estimate p , tu, fc: integer local to p 
begin 

1 estimate p := 

2 for fc := 1 to 2t -h 1 do 

3 w := propose(p, estimate p , 0*.) 

4 VJ>[fc] := w 

5 if (w ^ ±)A(u; ^ estimate p ) then 

6 esfamatep := it; 

7 V„[l . . . (Jb - 1)] := 

8 if Vp has more than t _L f s then 

9 retum(jL) 

10 else return (estimate p ) 
end 


Figure 2: t-tolerant gracefully degrading self-implementation of N-consensus for R-omission 


Claim 5.1 For every k, l < k < 2t + l, at the end of the k th iteration of the for-loop 
of Propose(p, t/ p , 0) in Figure 2 , estimatep € {0,1}, and contains only L’s and 

estimatep f s. 

Proof By an easy induction on k, □ 

Theorem 5.2 Figure 2 gives at-tolerant gracefully degrading self-implementation o/N-consensus 
for R-omission . 

Proof Let 0 be a derived N-consensus object of the implementation, and 0i, 02, • • • , 0 *+ 1 
be its base objects. Consider an execution E in which all base objects that fail, fail by R- 
omission. 

1. 0 is wait-free : Obvious since base objects that fail by R-omission remain wait-free. 

2. 0 satisfies validity: An easy induction on k shows that if estimate p equals some value 
u at any point in E , then there was a prior invocation (from some process q) of 
Propose^, u, 0). The induction will use Proposition 5.2, and the fact that p does 
not change estimate p if a base object returns _L 

7 As will be shown later in Theorem 7.2, there is no t- tolerant gracefully degrading implementation of 
N-consensus for R-crash. 
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3. O satisfies agreement : Suppose, for a contradiction, there exist two processes p and 
q such that Propose(p, v p , O) returns 0 and Propose^, 0) returns 1. From Claim 

5.1, and lines 8, 9 of the algorithm, it follows that V p has at least t + 1 0’s at the end 
of the execution of Propos e(p,v p , O ) and V q has at least t + 1 l’s at the end of the 
execution of Propose(g, v q , O). This is possible only if there is a k (1 < k < 2f+l) such 
that propose(p, estimate p , Ok) returned 0 and propose^, estimate q , Ok) returned 1. 
Thus Ok does not satisfy agreement. By Proposition 5.2, the failure of Ok in E is not 
by R-omission, a contradiction. 

4. O satisfies weak integrity : Obvious. 

5. O satisfies integrity if at most t base objects fail : Let Ofcj , 0*, , . . . , 0*, (fci < k 2 < 

... < k{) be all the correct base objects. Since at most t fail, we have / > t + 1. By 
Proposition 5.1, O*. , satisfies integrity and agreement. Thus, there is a v G {0, 1} such 
that for all p, propose(p, estimate p , O ^ ) returns v. Thus, for all p, estimate p = v at 
the end of k\ iterations of the for-loop in Propose(p, v p , O). Using this and Proposition 

5.2, it is easy to verify that at the end of the execution of Propos e(p,v p , 0), V p [k,] = v 
and estimate P = v for all p and for all 1 < i < l. This implies, by lines 8, 9 of the 
algorithm, that Propos e(p,v p ,0) returns v. 

From 1, 2, 3, and 4 above, and Proposition 5.2, we conclude that either O is correct 
in E, or O fails by R-omission in E. From 1, 2, 3, and 5 above, and Proposition 5.1, we 
conclude that if at most t base objects of O fail in E, O is correct in E. Thus, Figure 2 is 
a t-tolerant gracefully degrading self-implementation of N-consensus for R-omission. □ 

We now prove a general lower bound on the resource complexity of gracefully degrading 
implementations for R-omission. Informally, a type T is trivial if it admits the following 
implementation: there is a function / such that every Apply (P, op, 0) blindly returns f{op). 
More precisely, T is trivial if there is a function / : OP(T) -► RES{T) such that for every 
sequence op u op 2 , . . . ,op k of operations, (op u /(opi)), (op 2 , f(op 2 )), ..., ( op k ,f(op k )) is 
consistent with respect to T. An object type is non-trivial if it is not trivial. The following 
proposition is immediate from the definitions. 

Proposition 5.3 Let T be a deterministic non-trivial object type, and /o : OP(T) — * 
RES(T) be the function such that for all op, (op, fo(op)) is consistent with respect to T. 8 
Then there exists a k > 1 and a sequence op\,op 2 , . . . ,opk,opk+i of operations such that 
(opi,fo(opi)), ( op 2 , fo(op 2 )), . . . , (opk, fo(opk)) is consistent with respect to T, but (opi, fo(opi)), 
(°P 2 , fo(op 2 )), ■ ■ ■ , (opk, fo(opk)), (opk+ 1 , fo(opk+i)) is not. 

Theorem 5.3 Let T be any deterministic non-trivial object type. The resource complexity 
of any t-tolerant gracefully degrading implementation ofT for R-omission is at least 2t + l. 

Proof Suppose T has a t-tolerant gracefully degrading implementation I from some fist 
• • • »^2t of object types for R-omission. Let 0i,02, • • • ,02t be base objects of type 

Note that fo(op) is the response of an object of type T when op is the first operation applied to that 
object. 
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Ti, T 2 , . . . , Tit , and let 0 = 2(0i, 02, . . . , 02t) be the corresponding derived object (of type 
T). Let /o and opi, op2> • « * , op*, opk+i be as in Proposition 5.3. Consider the following 
scenario in which two processes P and Q access the object 0 . At the start of the scenario, 
object 0 is in the initial state, and all its base objects fail, as described below. 

For objects 0j, 1 < i < t: Whenever P invokes an operation on 0;, it returns a correct 
response to P and undergoes an appropriate change of state; but whenever Q invokes an 
operation on 0*, it returns J_ and does not undergo any change of state. For objects 0 ; , 
t + 1 < j < 2t: Whenever P invokes an operation on 0 ; , it returns _L and does not undergo 
any change of state; but whenever Q invokes an operation on Oj, it returns a correct 
response to Q and undergoes an appropriate change of state. 

Scenario S 

1 . Process Q executes the sequence op \ , op 2 , . . . , op*, of operations on 0 . Let v \ , vi , . . . , v*. 
be the corresponding responses. 

2. Process P executes opk+i on 0. 

(All steps in Item 1 strictly precede every step in Item 2). Note that: 

1. The failure of each base object is by R-omission. 

2. The scenario S is indistinguishable to Q from a scenario S' in which 0i,02,...,O< 
fail as above, but 0*+i,0*+2> . - • , 02* are correct. Since 0 is derived from a t-tolerant 
implementation, the responses to opi, op 2 , . . . , op*, returned by Q in S' must be correct. 
So the responses in S' must be /o(opi), /o(op 2 ), . . >,fo(opk), respectively. Since S and 
S' are indistinguishable to Q, Q returns the same responses in S. 

3. When P executes op on 0, the manner in which objects have failed makes it impossible 
for P to know whether Q previously executed any operations on 0. So, the scenario 
S is indistinguishable to P from a scenario S" in which (i) it is the first process to 
invoke an operation on 0, and (ii) only t base objects, namely 0*+i, 0^+2, • • ♦ > 02*. 
fail. Since 0 is derived from a t-tolerant implementation, P must return the correct 
response in S". So P must return /o(op*.+i) in S". Since S is indistinguishable to P 
from S", P also returns the response /o(apfc+i) in S. 

By Proposition 5.3, (opi, /o(opi)), (?P2, /o(^P2))» • • • > (°PJb> /o(op*))> (op*+i, f{op k +\)) is 
not consistent with respect to T. So, the history of object 0 in the above scenario is not 
linearizable with respect to its type T. Thus, 0 does not satisfy Property 3 of R-omission 
in Section 3.1.2. In other words, the failure of 0 is not by R-omission, even though the 
base objects of 0 have only failed by R-omission. This implies that I, the implementation 
from which 0 is derived, is not gracefully degrading for R-omission. □ 

5.1.3 Translation from R-arbitrary to R-omission 

A self-implementation T of object type T is a t-tolerant translation from a failure model Ai 
to a failure model M! for T if every derived object 0 of T satisfies the following property: 
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In every execution E , if at most t base objects of O fail, and fail by A4, then either O is 
correct or it fails by M! . Note that if no base objects fail in £?, then O does not fail either 
(this follows from the definition of implementation). 

In this section, we present a ^-tolerant translation from R-arbitrary to R-omission for 
N-consensus. We also show that its resource complexity, 3t + l, is optimal. This translation 
can be used along with the ^-tolerant self-implementation of N-consensus for R-omission 
(seen in Section 5.1.2) to obtain a t-tolerant self-implementation of N-consensus for R- 
arbitrary failures. 

Since a consensus object that experiences an R-arbitrary failure may return a non- 
binary response, we always “filter” the responses to get a binary response: procedure 
f-propose(p, v, O) returns propose(p, v, O) if it is 0 or 1, and returns 0 otherwise. 


A[1 . . . 2t + 1] , B[l . . . t] : N-consensus objects 

Procedure Propos e(p, v p , O) 

ccmn£ p [0..1], it;, i, belie f p : integer local to p 
begin 

1 Phase 1: count p [ 0..1] := (0,0) 

2 for i := 1 to 2t + 1 do 

3 w := f-propose(p, v p ,-A[i]) 

4 count p [w ] := count p [w] + 1 

5 Phase 2: Choose belief p such that 

count p [belief p } > count p [belief p ]. 

6 for i ~ 1 to t do 

7 if belief p ^ f-propo se(p, belie f p , B[i]) then 

8 retum(_L) 

9 return(6e/ie/p) 
end 


Figure 3: t-tolerant translation from R-arbitrary to R-omission for N-consensus 

Let O be an iV-consensus object derived from the translation in Figure 3. The base 
objects of O are A[ 1 . . . 2t + 1], B[ 1 . . . t]. 

Claim 5.2 O satisfies integrity in any execution in which all base objects of O are correct. 
Proof Clear from the algorithm. □ 

Claim 5.3 O is wait-free in any execution in which all base objects of O are wait-free . 
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Proof Clear from the algorithm. □ 

In the following claims, let E be an execution in which at most t base objects experience 
R-arbitrary failures, and the remaining are correct. 

Claim 5.4 O satisfies weak integrity in E. 

Proof Clear from the algorithm. □ 

Claim 5.5 O satisfies validity in E . 

Proof Suppose O returns v € {0, 1} to the invocation Propose(p, v p , O ) (from process p). 
Then v = belie f v (by line 9), and count p [v ] = count p [belief p ] > t4*l (by line 5). So there is at 
least one correct base object A[i ] such that propose (p>v p ,A[i]) returned v. By Proposition 
5.1, A[i] satisfies validity. It follows that some process q invoked propose^, v q , A[i]) where 
v q = v . This implies that q invoked Propose(g, v, O). □ 

Claim 5.6 O satisfies agreement in E. 

Proof Suppose O fails to satisfy agreement by returning v € {0,1} to some process p, and 
v to a different process q. O returns t; to p implies v = beliefs Similarly v = belie f q . We 
thus have belie f p ^ belie f q . It is easy to verify that if all of A[ 1 . . . 2t + 1] are correct, then 
belie f p = belie f q . It follows that at least one of A[ 1 . . . 2t 4* 1] fails. 

Further, O returns v to p implies, for all 1 < i < t, propose(p, belie f p , B[i}) returns 
belie f p = v to p. Similarly, for all 1 < z < i, propos e(q, belie f q , B[i]) returns belief q = v 
to q. Thus all t base objects B[ 1 . . . t] fail by not satisfying agreement. Counting the failed 
A[iy s and B[i]’s, we have more than t failed base objects, a contradiction. □ 

From the above claims, and Propositions 5.1 and 5.2, we conclude that: (i) O is correct 
in every execution in which all base objects of O are correct; and (ii) O is either correct 
or it fails by R-omission in every execution in which at most t base objects of O fail by 
R-arbitrary, and the remaining base objects are correct. Thus, 

Theorem 5.4 Figure 3 presents a t-tolerant translation from R-arbitrary failures to R - 
omission failures for N-consensus. The resource complexity of the translation is 3t + 1. 


Theorem 5.5 The resource complexity of any translation X from R-arbitrary to R-omission 
for N-consensus is at least 3t + 1. 

Proof For a contradiction, assume the resource complexity of I is n < 3 1. We prove 
the theorem through a series of claims, involving “indistinguishable” scenarios. Let O = 
Z(oi,c> 2 , . . . , o n ) . In the following, we say a process p accesses a base object Oi if during the 
execution of Propose (p, v p , O), p executes propose(p, *, Oi). 
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Claim 5.7 Suppose p executes Propose(p, 0, O) to completion . If all base objects are cor- 
rect , then p accesses at least t + 1 base objects. 


Proof Suppose the claim is false, and p accesses only , Oi 2 , . . . , o, m (m < t) before 
completing Propose(p, 0, (?). Since all base objects are correct, O satisfies validity and 
integrity. Hence Propose(p, 0, O) returns 0. Now consider the following two scenarios. 

Scenaxio SI 


1. p executes Propose (p, 0, 0) to completion accessing only , o, 2 , . . . , (m < t). 
Propose(p,0, C>) returns 0. 

2. q executes Propose^, 1, O) to completion. 

Scenario S2 

1. Oj, , Oi 2 , . . . , Oj m fail and behave as though they are accessed by p exactly as in scenario 
SI. This is possible since m < t. 

2. q executes Propose (g, 1, O) to completion. 

Since no base objects fail in SI, O must be correct in SI. By Proposition 5.1, O satisfies 
integrity and agreement. Thus Propose^, 1, 0) returns 0 in SI. Clearly SI zz q S2 (we 
write SI zz q S2 to denote that Scenarios SI and S2 are indistinguishable to process q). So 
Propose^, 1, O) returns 0 in S2 also, violating validity. By Propositions 5.1 and 5.2, O is 
neither correct nor does it fail by R-omission. Since at most t base objects fail in S2, and 
they fail by R-arbitrary, the translation I is incorrect, a contradiction. □ 

Claim 5.8 Consider 
Scenaxio S3 

1. p executes Propose(p,Q, O) up to the point where it has accessed exactly t base objects 

> 0*3 > 4 • • ? °i t * 

2. q executes Propose^, 1, O) to completion. 

Then Propose^, 1, O) returns 1. 

Proof Let S = {base objects accessed by q} - { 0il , o h , . . . , o it }. Let o h , 0jj , . . . , o jk be all 
the base objects in S arranged in order of first invocation of q. Note that k < n — t < 2t. 

Let S2 r represent scenario S2 when m — t. Since at most t base objects fail in S2\ 
and they fail by R-arbitrary, O must either be correct or fail by R-omission. Hence, by 
Propositions 5.1 and 5.2, O satisfies validity and weak integrity in S2'. So Propose^, 1, O) 
returns 1 or J. in S2'. Since S2* S3, we conclude Propose^, 1, 0) returns 1 or _L in S3. 

Since no base object fails in S3, O must be correct. By Proposition 5.1, O satisfies integrity 
in S3. So Propose^, 1, 0) returns either 0 or 1 in S3. Together with the above conclusion, 
this implies the claim. □ 
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Claim 5*9 Consider 
Scenario S4 


1. p executes Propose(p,0, O) up to the point where it has accessed exactly t base objects 

i i • ■ ■ ? ®it * 

2. Let Oj 1? Oj 2 ,. . . ,Oj h be as defined above (note k<2t), q executes Propose^, 1, O) up 
to the point where it has accessed exactly {oj x ,Oj 2 , . . . , Oj k _ t }. 

3. p completes the execution o/Propose(p, 0, O). 

Then Propose(p, 0, O) returns 0. 

Proof Consider 
Scenario S5 


1. p executes Propos e(j>, 0, O) up to the point where it has accessed exactly t base objects 

^il } > • • • > • 

2. The base objects Oj 2 , Oj 2 , . . . fail and behave as though they are accessed by q 

exactly as in S4. 

3. p completes the execution of Propose(p, 0, O). 

Since k < 2t, the number of base objects that fail in S5 = k — t < t. Since they fail 
by R-arbitrary in S5, either O is correct in S5, or O fails by R-omission in S5. Thus, by 
Propositions 5.1 and 5.2, O satisfies validity and weak integrity in S5. So Propose(p, 0, O) 
returns either 0 or J. in S5. Since clearly S4 S5, Propose(p,0, O) returns either 0 or ± 
in S4 also. However since no base object fails in S4, O is correct in S4, and by Proposition 
5,1, it satisfies integrity in S4. Thus Propose(p, 0, O) returns 0 in S4. □ 

Claim 5.10 Consider 
Scenario S6 


1. p executes Propose(p,0, O ) up to the point where it has accessed exactly t base objects 

i ) j 4 4 4 i ♦ 

2. q executes Propose^, 1, (9) to completion , returning 1, by Claim 5.8. 

3. Let Oj t , Oj 2 , . . . , Oj k be as defined above (note k < 2t). {o JJk _ t+1 , Oj fc _ t+2 , . . . , oj k } fail 
and behave as though they are never accessed by q. 

4. p completes the execution of Propose (p, 0, 0). 

Then Propose(p, 0, O) returns 0. 
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Proof Note that S4 S6. By Claim 5.9, Propose^, 0, O ) returns 0 in S4. So Propose(p, 0, O) 
returns 0 in S6. □ 


From the above claim, it is clear that O does not satisfy agreement in S6. Hence, by 
Propositions 5.1 and 5.2, O fails in S6, but not by R-omission. Since at most t base objects 
fail in S6, and they fail by R-arbitrary, the translation 1 is incorrect, a contradiction. This 
completes the proof of Theorem 5.5. □ 


5.1.4 Tolerating R-arbitrary failures 

Since N-consensus has a ^-tolerant translation from R-arbitrary to R-omission (of resource 
complexity 3t + 1), and has a ^-tolerant self-implementation for R-omission failures (of 
resource complexity t + 1), it follows that N- consensus has a ^-tolerant self- implementation 
for R-arbitrary failures. However the resulting self- implementation is expensive, requiring 
(3 1 + l)(t 4- 1) base objects. In this section, we present a t-tolerant self-implementation for 
R-arbitrary failures whose resource complexity is only O(tlogt). 9 This self-implementation 
uses the divide-and-conquer strategy. In Figure 4, we present the base step: obtaining a 
1-tolerant self-implementation of resource complexity 6. In Figure 6, we show the recursive 
step of obtaining a t - tolerant self- implementation from a t/2-tolerant self- implementation. 
Consider the 1-tolerant self- implementation of N- consensus given in Figure 4: 

Claim 5.11 Let i be either 1 or If at most one object among 0{ , 0 l+ lf and 0i +2 
fails, then Majority(p, 0», 0i+i, 0i+ 2 ,u) returns v only if there is a concurrent or preceding 
execution of Maj or ity (q, Oi , 0, + i , 0i+ 2 , v) . 


Proof Clear from the algorithm. □ 

Claim 5.12 Let i be either 1 or 4 . If no object among Oi, 0 i+1 , and0 l+2 fails , then , for all 
p andq, Majority(p, O,-, Oi+i, 0;+ 2 , v p ) returns the same value as Maj or ity (<7, 0 2 , 0;+i, 0^2 > Vq)- 

Proof Clear from the algorithm. □ 

Theorem 5.6 Figure 4 gives a 1-tolerant self-implementation of N-consensus for R-arbitrary 
failures . 

Proof Consider an execution E in which at most one of 0\ , 0 2 , . . . , 0 6 fails by R-arbitrary 
and the remaining are correct. Claim 5.11 implies that O satisfies validity in E . Clearly, 
either all of 0i,O 2 , and 03 are correct in E, or all of 04,05, and 0§ are correct in E. In 

9 This implementation, and all other implementations for R-arbitrary failures in this paper, are gracefully 
degrading. Graceful degradation for R-arbitrary failures is, however, almost trivial to achieve: it only 
requires that, if all base objects are wait-free, then the derived object is also wait-free. For brevity, we omit 
references to graceful degradation in this section. 
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Oi : N-consensus objects (1 < % < 6 ) 

Procedure Maj ority(p, Ox, 0 2 , 03 , v) 
countp[ 0 .. 1 ], w: integer local to p 
begin 

ccmnt p [ 0 .. 1 ] := ( 0 , 0 ) 
for i := 1 to 3 do 

u; := f-propose(p, v,Oi) 
count p [w] := count v [w] + 1 
if count p [ 0 ] > count p [ 1 ] then 
return(O) 
else return(l) 

end 

Procedure Propos e(p, v, O) 
begin 

v := Majority(p,Oi,0 2 ,0 3 , v) 
v := Maj ority(p,0 4 , 05 , 06 , v) 
return (v) 

end 


Figure 4: 1-tolerant self-implementation of N-consensus for R-arbitrary failures 


the latter case, Claim 5.12 implies that O satisfies agreement in E. In the former case, 
Claims 5.11 and 5.12 together imply that O satisfies agreement in E . It is obvious that O 
satisfies integrity, and is wait-free in E . Thus, by Proposition 5.1, O is correct in E. □ 

Given this 1 -tolerant self-implementation, by Booster lemma (Corollary 4.2) we obtain 
a t-tolerant self-implementation of N-consensus for R-arbitrary failures. However, the 
resulting resource complexity is 0(t l ° 63 6 ), which is even higher than the complexity of the 
implementation through translation mentioned above. 

A more efficient recursive algorithm is presented in Figure 6 . This algorithm implements 
a t-tolerant N-consensus object O from Ox, a -tolerant N-consensus object, 0 2 , a 
[ J .tolerant N-consensus object, and the following (0-tolerant) N-consensus objects: 
Ao[l . . . 3t + 1], Ai[l . . . Zt + 1] and B[1 . . . it + 1 ]. Figure 5 illustrates the order in which 
the base objects of O are accessed by a process proposing 0 on O (the access pattern for a 
process proposing 1 on O is symmetrical). 

Consider an execution E in which at most t base objects fail by R-arbitrary. Since 0\ 
is [^1 -tolerant and 0 2 is L^J -tolerant, either 0\ or 0 2 I s correct in E. The algorithm 
in Figure 6 is based on this key observation. We now sketch the intuition behind Figure 6 . 
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A process p executing Propose(p, v p , O) first executes f-propose(p, v p , Oi); if 0\ seems 
correct to p, p adopts the value returned by f-propose(p, v p , Oi) for Propose(p, v p , O). If 
p detects that 0\ failed, p uses O 2 to determine the response for Propose(p, v p , O). 

Process p uses objects Aq[1 . . . Zt 4- 1], Ai[l . . . 3t + 1] and J3[l . . . 4t + 1] to determine 
whether 0\ fails in B . 0\ can fail in one of the following ways: (i) by returning a value 
outside {0,1}, (ii) by returning a value v 6 {0,1} that was not proposed by any process, 
and (iii) by returning 0 to some processes and 1 to other processes. The first case is 
overcome by using f -propose as a “filter”. The second and third cases are detected by 
using A v [l . . . 3t + 1] and B[1 . . . 4i + 1] respectively. 

Note that the failure detection provided by Ao[l . . . 3t+ 1], A\[l . . . 3t+l] and B[1 . . . 4 £+ 

1] is not perfect. 0\ may seem correct to some processes, and these processes base their 
decision on Others processes may detect that 0\ failed and base their decision on O 2 . 

The implementation in Figure 6 uses B to guarantee that both sets of processes decide on 
the same value. We describe the implementation in Figure 6 by sketching how it overcomes 
the different types of failures that 0\ may exhibit: 

• 0\ returns a value that is not in {0,1}. As before, procedure f-propose “filters” the 
response to eliminate this problem. 

• Oi returns a value that was not proposed by any process. Ao[1...3t -f 1] and 
Ax[l . . . 3t + 1] axe used to detect that 0\ failed, as follows. 

Process p executes f-propose(p, v p , A Vp [i]), for 1 < t < 3t + 1, before executing 
anslp := f-propose(p, v p , Oi). It can be shown that if 0\ is correct in E , then all 
correct objects in A anJ i p [l . . . 3t + 1] are “set” to arts l p . Since a maximum of t objects 
in A a nsip[l • • • 3t + 1] may fail in p expects at least 2t + 1 objects to return ansl p 
when p accesses A ans i p [l . . . 3t -f 1]. If p gets fewer than 2t 4- 1 copies of arts l p , p 
knows that 0\ failed in E. Thus^p uses O 2 to reach the decision value. 

• Oi may return 0 to some processes and 1 to others processes. B[1 . . . 4t + 1] are used 
to detect that 0\ failed, as follows. 

Immediately after executing ansl p := f -propose(p, v pi Oi), p executes f-propose(p, an^l^, J5[i]) 
for 1 < i < 4t+l. If 0\ is correcting, no process q will execute f-propose(g, ansl p , B{i}) 
for 1 < i < 4t + 1. Thus, all correct objects in B[ 1 . . . 4t -f 1] will be “set” to ansl p . 

Since a maximum of t objects in B[1 . . . At + 1] may fail in B, p expects at least 3t + 1 
objects to return ansl p when p accesses B[1 . . . 4t + 1]. If p gets fewer than 3t -1- 1 
copies of anslp, p knows that 0\ failed in E. Thus, p uses O 2 to reach the decision 
value. 

If p detects that 0 1 failed in B, p uses O 2 to reach a decision. Recall that it is possible 
that some other process q did not detect Oi’s failure, hence Propos e(q^v qj O) returned 
anslq. In this case, q gets at least 3t + 1 copies of ansl q from B[ 1 . . At + 1]. To ensure 
that p agrees with q in this case, p proposes to O 2 the value v p , which is the majority value 
that it got from B[1 . . . it + 1]. Note that care is taken to ensure that v p is valid: p should 
have received at least t + 1 copies of v f p when p accessed A^[l . . . 3t + 1]. We now prove: 
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Ao[l . . . 3t + 1], Ai[l . . . 3t + 1], B[1 . . . 4t + 1] : (O-tolerant) N-consensus objects 
0\ : -tolerant N-consensus object 

O 2 : L^J -tolerant N-consensus object 

Procedure Propose (p, v p , O) 

countp [0..1], WitnessCountp[ 0..1], belie f p) ansl py ans2 p , z/p, z, iy : integer local to p 
begin 

1 countp[ 0..1] } W' r ztnessCountp[0..1] := (0,0) 

2 Phase 1: for i := 1 to 3t + 1 do 

3 w := f-propose(p,i> p , A Vp [i]) 

4 if w = t; p then cotzntp[vp] := count p [v p ] -hi 

5 Phase 2: anslp := f-propose(p, v p? 0\) 

6 Phase 3: for i := 1 to 4t + 1 do 

7 zy := f-propose(p, nnslp, B[i]) 

8 WitnessCountp[w] := WitnessCount p [w] + 1 

9 Phase 4: for i := 1 to 3t + 1 do 

10 w ~ f-propo se(p,Vp,A^[z]) 

11 if iy = then count p [v^] := countp [v^]+l 

12 Phase 5: Choose belief p such that WitnessCount p [beliefp] > WitnessCount p [belief p ] 

13 if WitnessCountp[belief p ] > 3t + 1 and count p [belief p ] > 2t + 1 then 

14 retum(6e/ze/p) 

15 if WitnessCount p [beliefp ] > 2t + 1 and count p [belief p ] > t + 1 then 

16 v' p := beliefp 

17 else Vp := v p 

18 ans2 p := propose(p, v' pi 0 2 ) 

19 return(ans2p) 
end 

Figure 6: Efficient t-tolerant self-implementation of N-consensus for R-arbitrary failures 
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Theorem 5.7 Figure 6 gives a t -tolerant self-implementation of N-consensus for R-arbitrary 
failures of resource complexity 0(t log t) . 

Proof Consider an execution E in which at most t base objects fail by R-arbitrary, and 
the remaining are correct. We show below, through a series of claims, that O is correct in 
E ; or equivalently (by Proposition 5.1), that O satisfies validity, agreement, and integrity, 
and is wait-free in E> 

Proposition 5.1 is used very often in this proof. For brevity, we omit references to it. 
Claim 5.13 If O \ fails in E, then O 2 is correct in E. 

Proof Suppose both 0\ and O 2 fail in E. Since Oi is derived from a -tolerant 
implementation, at least [^] + 1 base objects of 0\ must fail in E . Similarly, at least 
L^J + 1 base objects of O 2 must fail in E. Thus a total of [^] + + 2 > t base 

objects of O fail in E y a contradiction to the definition of E . □ 

Claim 5.14 If 0\ is correct in E, O satisfies validity and agreement in E. 

Proof Suppose 0\ is correct. Thus, 0\ satisfies validity and agreement. By the agreement 
property of Oi, ans l p = ans l q for all p, g. (Let v = ans l p .) Thus every process proposes 
the same value v to every B[i\ in Phase 3. Since at most t objects in B[ 1 . . At + 1] fail, 
belie f p = v and WitnessCount p [belief p ]> 3t + 1 (for every p). 

By the validity property of 0 1 , some process q will have invoked propose^, v, 0\) 
before any process gets the response v from 0\. This implies that q will have finished Phase 
1 before any process begins Phase 3. Since at least 2t + 1 objects in A v [l . . . Zt 4* 1] axe 
correct, it follows that for all p, count p [v]> 2t + 1 by the end of Phase 4 of p. Thus we have 
WitnessCount p [belief p ] > 2t -f 1 and count p [belief p \ > 2t + 1 (for every p). Hence every p 
decides v (the proposal of q) by line 14. □ 

Claim 5.15 If 0\ fails in E } O satisfies validity and agreement in E. 

Proof Suppose 0\ fails. Then by Claim 5.13, O 2 is correct, and thus, satisfies validity and 
agreement. We need to consider two cases. 

CASE 1 Suppose some process p returns by line 14. This implies that WitnessCount p [belie f p ] 
> 3t 4- 1 and count p [belief p \ > 2t + 1. Since at most t base objects fail, it follows that, 
for every g, WitnessCount q [belie f p ] > 2t 4* 1 find count q \belief p ] > t + 1. By fine 12, this 
implies that belie f q = belie f p . Let val = belie f p . Since WitnessCountq [belie f q ] > 2t 4* 1 
and count q [belief q ] > 1 4* 1, either q returns belie f q = val by Une 14 and we have agreement 
between p and g, or q sets v q to belie f q by line 16, making v q equal to val . Thus every g, 
that does not return by line 14, proposes v q = val on O 2 . By the validity property of 02, 
ans2 q = val , and g returns val by line 19. Again we have agreement between p and q. 


26 



To see that O satisfies validity, note that count p [belief p ] > 2t + 1 imphes that some 
process proposed belie f p = val on at least t + 1 objects in -A6e/, e / p [l . . . 3< + 1]. 

CASE 2 Suppose no process returns by line 14. Then every q returns ans2 q by line 19. 
By the agreement property of O 2 , for all p,q, we have ans2 p = ans2 q . (Let val = ans2 p ). 
Thus, O satisfies agreement. 

By the validity property of O 2 , some process p must have proposed val to O 2 . That 
is v' p = val. In the algorithm, v p equals either v p or belief p . If v' p = v p , then clearly O 
satisfies validity. If v p = belie f p ^ v p , then p must have executed line 16. It follows that 
count p [belief p }> t + 1. Since at most t objects in -A&elte/ P [l . . . 3t + 1] fail, some process q 
proposed v q = belie f p on some object in Af*,/ ie/p [l . . . 3t + 1]. Thus, process q proposed v q 
on O. Thus, O satisfies validity. □ 

Claim 5.16 The resource complexity of the implementation in Figure 6 is 0[t log t) . 

Proof Denoting the resource complexity of the t-tolerant self-implementation of N-consensus 
for R-arbitrary failures by /(<), we have the following recurrence: f(t) = 2/ (i/2) + 2(3 1 + 
1) + (4 1 4- 1) and /(l) = 6. □ 

It is obvious that O satisfies integrity and is wait-free in E. By Claims 5.14 and 5.15, 
O satisfies validity and agreement in E. Thus, by Proposition 5.1, O is correct in E. This 
completes the proof of Theorem 5.7. □ 

5.2 Fault- tolerant implementation of register 

The register type supports two operations, read and write v. The sequential specification 
is simple: read returns the value most recently written. 

In [Lam86], Lamport defined three types of registers: safe, regular, and atomic. Atomic 
register corresponds to register in our terminology. A safe register is not linearizable, but 
it satisfies the following: a read operation that does not overlap with a write, returns the 
latest value written into the register. A read that overlaps with a write may return an 
arbitrary value. 

In the following, we first show how to build a fault-tolerant safe register from safe regis- 
ters, some of which may experience R-arbitrary failures. We then resort to the register con- 
struction results in the literature to show that register has a t-tolerant self-implementation 
for R-arbitrary failures. 

Lemma 5.1 A t-tolerant 1-reader, 1-writer, n-valued (resp. unbounded) safe register can 
be implemented from 2t + 1 1-reader, 1-writer, n-valued (resp. unbounded) safe registers, at 
most t of which may experience R-arbitrary failures. 

Proof (sketch) The implementation is as follows. To read the derived safe register, the 
reader reads all 2< + 1 base registers, and returns the majority response. If there is no 
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majority, it returns an arbitrary value. To write a value v into the derived register, the 
writer writes v to all 2t + 1 base registers. It is easy to verify that the above scheme 
implements a safe register that is correct even if at most t base registers experience R- 
arbitrary failures. □ 

Since one can implement a multi-reader, multi-writer n-valued (resp. unbounded) atomic 
register using 1-reader, 1-writer, boolean (resp. unbounded) safe registers, we have: 

Theorem 5.8 boolean register and unbounded register have t-tolerant self-implementations 
for R-arbitrary failures . 

5.3 Universality results 

We now describe how to implement fault-tolerant objects of a generic type. Let N-consensus 
with reset be an iV-process object type informally defined as follows: In addition to pro- 
pose 0 and propose 1 operations, N-consensus with reset supports a reset operation. 

The reset operation re-initializes the object so that it may be used for a fresh round of 
consensus (see Appendix D for a formal specification of this type). 

Herlihy showed that every finite object type 10 has an implementation from (N-consensus 
with reset, unbounded register) 11 [Her91]. The use of unbounded registers can be re- 
placed by boolean registers [Plo89, JT92]. Using this result, together with Theorems 5.7 
find 5.8, we obtain the following corollary. 

Corollary 5.1 Let At be any responsive failure model , and T be any finite object type . 

• T has a t-tolerant implementation from (N-consensus with reset, boolean register) 
for At. 

• 7/N-consensus with reset and boolean register have gracefully degrading imple- 
mentations from T for At, then T has a t-tolerant self -implementation for At. 


Herlihy’s construction can be easily modified to yield a universal implementation from 
(N-consensus with reset, unbounded register) even for infinite object types. Thus, 

Corollary 5.1 holds even for an infinite object type T, provided that boolean register is 
replaced by unbounded register in the statement of the corollary. 

The types f etch&add, queue, stack, test&set implement 2-consensus, and compare&swap , 
move, swap implement N-consensus [Her91]. 

It is easy to show that corapare&swap, move, swap, test&set implement boolean 
register, and fetch&add, queue, stack implement unbounded register. Furthermore, 
all these implementations are gracefully degrading for R-arbitrary failures. Thus, 

10 Notice that, by our definition of object type, every object type has a “sequential implementation”. 

11 For this implementation, it suffices if the reset operation on an JV-consensus object works in the absence 
of concurrent operations on that object. 
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Corollary 5.2 The following object types have t-tolerant self-implementations for R-arbitrary 
failures: (2-process) fetch&add, queue, stack, test&set, and (IV-process) compare&swap , 
move, swap. 

6 Tolerating non-responsive failures 

So far we have considered base objects that remain responsive (i.e., wait-free) even if they 
fail. Thus, a process can access a base object and afford to wait for a response before 
proceeding to access the next one. In other words, base objects can be accessed sequentially. 
With non-responsive failures, waiting on a base object that fails could block the process 
forever. Hence, to tolerate non-responsive failures, we allow a process to access base objects 
“in parallel” 12 , so that it can complete its operation on the derived object even if some of 
the base objects fail and never respond. 

As we will see, this ability to access base objects in parallel allows us to build t-tolerant 
implementations of register, even for arbitrary failures. In contrast, we show that N-consensus 
does not have a (deterministic) implementation that tolerates the crash of a single base ob- 
ject even if we do not restrict the number and the type of the base objects that can be 
used in the implementation. However, randomization circumvents this impossibility result. 
Every object type has a t-tolerant randomized implementation from register, even for 
arbitrary failures. 

The impossibility results of this section are proved by reducing the consensus problem 
[PLP85] to the problem in question. The consensus problem for a system of N processes is 
defined as follows. Each process p, has an initial binary input v,. The consensus problem 
requires each correct process to reach the same (irrevocable) decision value d such that 
d € {ui,u 2 ,...,ujv}- 

Theorem 6.1 There is no 1-tolerant implementation of 2-consensus for crash failures. 

Proof Suppose, for contradiction, there is a finite list C - {Ti, T 2 , . . . ,7/} of object 
types such that there is a 1-tolerant implementation I of 2-consensus from C for crash 
failures. We will use this implementation to solve the consensus problem among a set of 
1 + 2 processes, one of which may crash, in a system in which processes communicate only 
through registers. 

Consider the concurrent system S consisting of / + 2 processes named {pi , p 2 } U {qj j 1 < 
j < 1}, and 4/ -I- 1 registers named {invocation(i, j), response(j,i) jl < i < 2,1 < j < 

/} U {decision}. We claim that the consensus problem is solvable in 5 even if one process 
crashes. The following is the protocol. Let v { 6 {0,1} be the initial input of p,. The basic 
idea consists of two steps: 

However, we do not allow a process to invoke an operation on a base object if its previous invocation on 
that object is still pending. 
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L Use a set {oi , 02 , . . . ? o\ } of base objects of type T\, T 2 , - . . , 7), and the implementation 
X, to construct a 2-consensus object O = X(oi,...,o;) that tolerates the crash of 
one of its base objects. 

2. In system S, process qj (1 < j < l) simulates the base object Oj, and process p l 
(i = 1,2) simulates the execution of Propose (p t , v*, 0) on the derived object O. 

The details are given below. 

Initialize all 4/ + 1 registers to _L. Process pi simulates Propose (p*, CO as follows. 
If Propose (pi, C?) requires pi to invoke some operation op on Oj, pi appends op to the 
contents of invocation(i,j). If Propose^, v*, CO requires pi to check if a response to some 
outstanding invocation on Oj has arrived, pi checks if a response has been appended by qj 
(which simulates oj) to response(j,i). If Propose (p,*,^, O) returns a value v, pi first writes 
v in decision register, and then decides v . In addition to (and concurrently with) the above, 
Pi periodically checks if the register decision contains a non-J_ value. If so, it decides that 
value. 

Process qj simulates the base object Oj as follows. Periodically qj checks the registers 
invocation[\, j) and invocation(2, j) , in a round-robin fashion. If qj notices that some op- 
eration op has been appended to invocation^, j), qj simulates the application of op to Oj 
and appends the corresponding response to respon$e(j,i). In addition to (and concurrently 
with) the above, qj periodically checks if the register decision contains a non-1. value. If so, 
it decides that value. 

The above simulation protocol solves the consensus problem among the l + 2 processes 
in the concurrent system 5, even if one of them crashes. To see this, consider any execution 
E of the concurrent system S in which at most one process crashes. Let E* be the corre- 
sponding “simulated” execution of the derived object O. Note that the crash of one process 
in S corresponds to the crash of at most one (simulated) base object of the (simulated) de- 
rived object O in E 9 . Since X, the 2-consensus implementation from which O is derived, is 
1-tolerant for crash, O is correct in E f (despite the crash of one of its base objects). Thus, 
by Proposition 5.1, O satisfies integrity, validity, and agreement, and is wait-free in E f . 
Since O is wait-free (in E ')» if Pi does not crash, Propose (p», V{,0) eventually returns some 
value v (in E '), Since O satisfies integrity, v is a binary value. Since O satisfies validity, v 
is either v\ or v 2 . Since O satisfies agreement, Propose (pi, v\, O) and Propose (p2> O) 
never return different values. Thus, from the protocol, p\ and P 2 do not write different 
values in register decision . Since at most one process crashes, at least one of p\ and P 2 will 
eventually write a binary value v in register decision . Since all correct processes periodically 
check the decision register, they eventually decide v. 

We showed that we can use X to solve the consensus problem in system 5, and this 
contradicts the impossibility result of Louis and Abu-Amara [LAA87]. □ 

We can strengthen the above result as follows. Suppose that at most one base object 
may fail, and it can only do so by being “unfair” (i.e., by not responding) to at most 
one process. Furthermore, suppose that the identity of this process is a priori “common 
knowledge” among all the processes. Even with this extremely weak model of object failure. 


30 



called l-unfaimess to a known process , we can prove the following: 

Theorem 6.2 There is no 1-tolerant implementation of 2-consensus for 1-unfairness to 
a known process. 

Proof ( sketch) Suppose, for contradiction, there is a finite list C = {Ti, T 2 , . . . , T/} of 

object types such that there is a 1-tolerant implementation 1 of 2-consensus from C for 
l-unfaimess to, say, process p x . Consider the concurrent system 5, as defined in the proof 
of Theorem 6.1. Suppose processes in 5 run the same simulation protocol as in that proof. 
There are two cases: 

1. No process q k crashes. In this case, it is easy to see that processes in 5 solve the 
consensus problem (exactly as before). 

2. Some process q k crashes. In this case, processes in S may fail to solve the consensus 
problem for the following reason. The crash of q k corresponds to the crash of the 
simulated base object o k . This object is now potentially unfair to bothpi and p 2 . But 
1 tolerates unfairness to only So the derived 2-consensus object O of 1 is not 
necessarily correct. 

To circumvent the problem that arises in Case 2, we modify the simulation protocol 
as follows: If Propose (p 2 , v 2 , O') requires p 2 to invoke some operation op on some Oj, p 2 
appends op to the contents of invocation(2,j), as before, but now it also waits until a 
corresponding response is appended to response(j, 2) by process qj. The rest of the simu- 
lation protocol remains exactly as before. We now reconsider the above two cases with the 
modified simulation protocol: 

1. No process q k crashes. As before, it is easy to see that processes in 5 solve the 
consensus problem. 

2. Some process q k crashes. If p 2 attempts to access o k after the crash of q ky it will 
simply wait for the response forever 13 . Therefore, at worst, to process p\, the crash 
of q k looks like o k is unfair to p u and p 2 is extremely slow. Since 1 tolerates the 
unfairness of one base object to p\ y O remains correct. Since p\ does not crash (we 
assumed that only one process in S crashes, and this is q k ), Propose^, tq, O) returns 
a value that p\ writes into decision . The rest of the proof is as in Theorem 6.1. 

Again, we have a contradiction to the impossibility result in [LAA87]. 

□ 

Prom the above two theorems we have: 

13 Of course, it also continues to read the decision register periodically, and decides if a non-1 value is 
fonnd there. 
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Corollary 6.1 If type T implements 2-consensus, then there is no 1-tolerant implemen- 
tation ofT for crash or for 1-unfaimess to a known process. 

Prom [Her91] and this corollary, we conclude that compare&swap, f etch&add, move, queue, 
stack, sticky-bit, swap, test&set, and several other common types do not have a 1- 
tolerant implementation for crash or 1-unfairness to a known process. In contrast to the 
above impossibility results we show 

Theorem 6.3 boolean register and unbounded register have t-tolerant self-implementations 
for arbitrary failures. 

This follows immediately from the following lemma and the fact that one can implement 
a multi-reader, multi-writer n-valued (resp. unbounded) atomic register using 1-reader, 
1-writer, boolean (resp. unbounded) safe registers. 

Lemma 6.1 A t-tolerant 1-reader, 1-writer, n-valued (resp. unbounded) safe register can 
be implemented from 5t + l 1-reader, 1-writer, n-valued (resp. unbounded) safe registers, at 
most t of which may experience arbitrary failures. 

Proof (sketch) Informally, the reader invokes a ‘read’ on each base register (the reader 
delays this read if its previous read on the base register is still pending). When it gets a 
response from At + 1 distinct registers, it returns the majority value. If there is no majority, 
it returns an arbitrary value. To write a value v, the writer invokes a ‘write v' on each 
base register (again, this write is delayed if the previous write on the base register is still 
pending). The writing completes when 4f + 1 base registers return an “ack”. It is easy to 
verify that the above scheme implements a safe register that is correct even if at most t 
base registers experience arbitrary failures. □ 

Randomized implementations of N-consensus from register are well known (for ex- 
ample, see [Asp90]). Together with Theorem 6.3, this implies that randomized t-tolerant 
implementations of N-consensus from register exist for arbitrary failures. Combining 
this with Theorem 6.3 and the universality results of [Her91, Plo89], we have 

Theorem 6.4 Every finite object type has a randomized t-tolerant implementation from 
boolean register for arbitrary failures, and every infinite object type has a randomized 
t-tolerant implementation from unbounded register for arbitrary failures. 

Thus, if a finite (resp. infinite) object type T implements boolean register (resp. 
unbo un ded register), then T has a randomized t-tolerant self-implementation for ar- 
bitrary failures. This implies that compare&swap, f etch&add, queue, move, stack, 
swap, test&set have t-tolerant randomized self-implementations, even for arbitrary fail- 
ures! 

Our next result concerns the nature of arbitrary failures. It states that the problem 
of tolerating arbitrary failures can be reduced to two strictly simpler problems: tolerating 
R-arbitrary failures and tolerating omission failures. 
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Lemma 6.2 (Decomposability of arbitrary failures) A type T has a t-tolerant self-implementation 
for arbitrary failures if and only ifT has a t-tolerant s elf -implementation I a for R-arbitrary 
failures , and I 0 for omission failures. 


Proof (sketch) The “only if” direction is obvious. To prove the “if” direction, define 
= T 0 (T a (oi,...,o m ),... 7 T a (o( n _ 1 ) m+1 ,...,o nm )). It can be verified that 
T is a t-tolerant self-implementation of T for arbitrary failures. □ 


7 Graceful degradation for benign failure models 

We have seen that every object type has a t-tolerant implementation for R-crash and R- 
omission failures. But what if we also require the implementation to be gracefully degrading? 
The results axe mostly negative for R-crash, but not so for R-omission. 


7.1 R-crash 

Consider a system that supports a given set S of “hardware” objects. Assume that these 
objects may fail, but if they do, they are guaranteed to only fail by R-crash. Suppose we 
wish to implement an object O of type T using only objects in 5, and that we require O 
to function correctly only in the absence of failures. However, when objects in S fail by 
R-crash, we would like O to fail only by R-crash. This last requirement is desirable for two 
reasons: 

• The benign failure semantics of R-crash sire desirable. 

• Such an object O appears like any other hardware object of the system. In other 
words, with this “software implementation” of O, the system would be no different, 
in functionality and failure semantics, from one that directly supports all the objects 
in S U { O } in hardware. 

In our terminology, we are seeking a gracefully degrading implementation of T for 
R-crash from the types (of the objects) in S. Unfortunately, as we show below, many 
object types do not have such implementations, even from very powerful object types. 
This negative result implies that, in many cases, the simple and desirable R-crash failure 
semantics cannot be achieved. 

An object type T is order-sensitive if it is deterministic and the following holds: There 
exists a state S in G(T), operations op, op' (not necessarily distinct) in OP(T ), and values 
u,v,u' ,v' such that each of ( op,u),(op',u ') and (op 1 , v'),(op, v) is consistent from the state 
5 of T, and u ^ v and u' v'. Intuitively, when an object O is in the state 5, and 
two processes p and q invoke operations op and op' concurrently on O, they can, based 
on the return values, determine the order in which their operations are linearized, queue 
is an example of an order- sensitive object type. To see this, let 5 be the state in which 
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there are two elements 5 and 10 in the queue (5 at the head), and let both op and op f 
be deq. Now we have u = 5, u f = 10, v f = 5, and v = 10. Thus u ^ v and u r ^ v f , 
as required, compare&swap, N-consensus, stack, test&set are some other examples of 
order-sensitive object types. An object type is non-order-sensitive if it is deterministic and 
not order-sensitive. Examples of non-order-sensitive types include register, sticky-bit, 
move, and swap. 

Theorem 7.1 There is no gracefully degrading implementation of any order- sensitive ob- 
ject type for R-crash from any list of non- order- sensitive object types . 

Proof Suppose there are T, £, and 1 such that T is an order-sensitive type, C = 
{Ti , T 2 , . . . , T n } is a list of non-order-sensitive types, and I is a gracefully degrading imple- 
mentation of T from C for R-crash. We arrive at a contradiction after a series of claims 
involving bivalency arguments [FLP85] and indistinguishable scenarios. 

Let O = J(Oi, O 2 , . . . ,O n ), and op,op',S,u,v,u\v f be as given in the definition of 
an order- sensitive type. Consider the concurrent system consisting of two processes p and 
q , and the shared object O (implemented from Oi, O 2 , . . . , O n ). Define the configuration 
(at an instant t) as the tuple (5 P , S qy S 0 ) where 5 P , S q , and S a are the states of process p, 
process q, and object O respectively (at the instant t). Let Co denote the configuration in 
which O is in state 5, and p, q are about to execute Apply(p, op, O) and Apply(g, op', 0) 
respectively. 

Claim 7.1 Suppose all base objects are correct. For any interleaving of the steps in the 
complete executions of Apply (p, op, O) and Apply (q, op', O), either kpply(p, op, O) returns 
u and Apply(g, op', O) returns u' , or Apply (p, op, C?) returns v and Apply {q, op', O) returns 
v'. 

Proof In the linearization of the execution history of object O y either Apply (p, op, O ) imme- 
diately precedes Apply(g, op', O), or Apply(g, op', O) immediately precedes Apply (p, op, O). 
This, together with the definitions of u, u', v, v f , and the fact that T is a deterministic type, 
trivially imply the claim. □ 

Let C denote a configuration reached from Co after some interleaving of (partial) exe- 
cutions of Apply (p,op, O) and Apply(g, op', O ). We say C is X -valent if, in the absence of 
base object failures, Apply (p, op, O ) returns X , no matter how the steps of Apply (p, op, O) 
and Apply(g, op', C) interleave when execution resumes from C. By Claim 7.1, if C is X- 
valent, either X = u ox X = v. C is monovalent if C is either u- valent or v- valent. C is 
bivalent if it is neither u- valent nor v- valent. 

Claim 7.2 Co is bivalent. 

Proof Starting from Co, if p completes all the steps of Apply (p, op, C) before q starts 
Apply(g, op', O), then Apply (p,op,0) returns u. Thus Co is not v-valent. 


34 



Similarly, starting from Co, if q completes all the steps of Apply(g, op', O) before p starts 
Apply (p, 0)> then Apply(g, op\ O) returns v * . Thus, by Claim 7.1, when Apply (p, op, O) 

completes, it returns v. Thus Co is not u- valent. 

Since Co is neither u - valent nor v- valent, it is bivalent. □ 

We say C f is a reachable configuration from C, if, starting from the configuration C, 
there is some interleaving of the steps of p and q such that C r is the configuration at the 
end of that interleaving. Given a configuration C, let C(p) denote the configuration that 
results when p takes a single step of Apply (p, op, O ) from C. C(q) is similarly defined. 

Claim 7.3 There is a bivalent configuration C cr it reachable from Co such that C cr i t (p) and 
Ccrit{q ) ar e both monovalent . 

Proof Interleave the steps of Apply (p, op, C) and Apply(g,op',C?) as shown in Figure 7. 
Since O is wait-free, the repeat . . until loop in the figure must terminate after a finite number 
of iterations. Let C^a be the value of C just when the loop terminates. It is easy to verify 
that Ccrit satisfies the properties required by the claim. □ 


C :=C 0 

repeat 

if C(p) is bivalent then 

C := C(p) 

ifC(q) is bivalent then 
C := C(q) 

until ( C{p ) is monovalent)A(C(g) is monovalent) 

Figure 7: Reaching a critical bivalent configuration 


Since C^t is bivalent, Ccrit (i>) and Cmt(«) cannot both be X- valent, for the same X. 
Thus, either C^tCp) is u-valent find Ccrit{q) is v- valent, or Ccrit (p) is v- valent and C CTlt {q) 
is u- valent. Without loss of generality, we will assume the former. 

Claim 7.4 The enabled steps of p and q in C cr i t access the same base object. 

Proof Suppose not. Then {C crlt (pj)(q) and (C CTl t(q))(p) are identical configurations, and 
yet, the former is u - valent and the latter v- valent. This is impossible since u ^ v. □ 

Assume that Ok is the base object mentioned in the above claim, and Apply (p, oper, Ok ) , 
Apply(g» ope^, O k ) are the enabled steps of p and q respectively in Ccrit- Since Ok is an ob- 
ject of a non-order-sensitive type, either Apply(g, oper' , Ok) returns the same value whether 
applied in Ccrit or Ccrit (p)i or Apply (p, oper, Ok) returns the same value whether applied in 
Ocrit ° r Ocrit(q). In the following, we will deal with the former case. The latter case can be 
handled similarly, and is omitted. 
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Claim 7.5 Consider 

Scenario SI (Starts from the configuration Cera) 


1. Process q takes the step Apply(g, oper', Ok)- 

2. Process p completes the execution of Apply (p, op, O). 

3. All base objects Oi, 02, . . . , O n fail by R-crash. 

4 . Process q resumes and completes the execution of Apply (q, op*, O). 

Then Apply (p, op, O ) returns v and Apply (g, op', 0) returns v ! . 

Proof Since g takes the step from <7^*, and Ccri*(9) is v- valent, and no base object failures 
occur before p completes the execution of Apply (p, op, 0) in Item 2, Apply(p, op, 0) returns 
v in Item 2 of the scenario. 

Suppose Apply(g, op', 0) returns JL. Since J is gracefully degrading, O must either 
be correct or fail by R-crash. Given that Apply (p, op, (7) returns a non-J_ response, this 
requires that Apply (p, op, O) precedes Apply(g, op', O) in the linearization order. Doing so, 
however, implies that (op, v) is a sequential execution from S consistent with T . This is 
false since (op, u) is the only sequence consistent from the state 5 of T, and v ^ u. Thus 
Apply(g, op', 0) cannot return J_. 

Suppose Apply(g, op', 0) returns w where _L ^ w ^ v f . Since in the linearization, ei- 
ther Apply(p, op, O) precedes Apply (g, op', 0), or Apply(g, op', 0) precedes Apply (p, op, (7), 
it follows that either (op,v),(op r ,w) or (op r ,w),(op,v) is a sequential execution from S con- 
sistent with T. This is false since (op,u),(op' ,u') and (op',v'),(qp,t;) are the only sequences 
consistent from the state S of T, and u ^ v, w ^ v f ^ v. 

We conclude that Apply(g, op', 0) must return v f . □ 

Claim 7.6 Consider 

Scenario S2 (Starts from the configuration Ccrit) 

1. Process p takes the step Apply (p,oper, 0*.). 

2. Process q takes the step Apply (g, oper', 0*.). 

3. Process p resumes and completes the execution 0 / Apply (p, op, (9). 

4- All base objects Oi, O 2 , . . . , O n fail by R-crash. 

5. Process q resumes and completes the execution of Apply(g, op', O). 

Then apply (p, op, O) returns u and Apply(g, op', O) returns v f . 
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Proof Since p takes the step from C^-*, and C CT it(p) is u-valent, and no base object failures 
occur before p completes the execution of Apply(p, op, O) in Item 3, Apply(p, op, O ) returns 
u in Item 3 of the scenario. Since S2^ g Sl, Apply(g, op\ O) returns v f as in SI. □ 

Neither (op, u),(op', v') nor (op r ,v r ),(op,u) is a sequence consistent from the state 5 of 
T. Hence the execution in Claim 7.6 is not linearizable. Thus the failure of O in S2 is not 
by R-crash. We conclude that X is not a gracefully degrading implementation for R-crash, 
a contradiction which concludes the proof of Theorem 7.1. □ 

Preserving the failures semantics of the underlying system is a desirable property of 
an implementation. For R-crash, the above theorem shows that this property is often not 
achievable: implementations necessarily amplify the R-crash failures of base objects. For 
example, consider a system that supports registers and sticky- bits in “hardware”. In such 
a system, any object can be implemented [Plo89], including (for example) queues. Suppose 
we are given the following guarantee: if any of the given registers or sticky bits fail, they fail 
only by R-crash. Can we implement a queue that cannot fail more severely than R-crash? 
The above theorem shows that this cannot be done. 

Requiring a derived object to inherit the R-crash semantics of its base objects is even 
more difficult if we add the requirement that the derived object be 1-tolerant: Even if we do 
not restrict the types of primitives available in the underlying system, such implementations 
do not exist for most objects of interest. This is shown by the theorem below. 

Theorem 7.2 There is no 1-tolerant gracefully degrading implementation of any order- 
sensitive object type for R-crash. 

Proof Suppose there are T, £, and I such that T is an order-sensitive type, £ = 
{Tx, T 2 , . . .,T n ) is a list of types, and X is a 1-tolerant gracefully degrading implementation 
of T from £ for R-crash. We arrive at a contradiction after a series of claims involving 
indistinguishable scenarios. Let O = X{0\^ 02> * * • O n ), and op, op 7 , 5, u, u, u r , v f be as 
given in the definition of order-sensitive types. Suppose O is in state 5, and p, q are about 
to execute Apply(p, op, 0) and Apply (g,op',0) respectively. 

Claim 7.7 Suppose all base objects are correct. For any interleaving of the steps in the 
complete executions of Apply (p, op, O) and Apply (q, op' ,0), efr/ier Apply (p, op, 0) returns 
u and Apply (q,op f ,0) returns u' , or Apply (p, op, O) returns v and Apply (q,op f , Q) returns 
v f . 

Proof Same as Claim 7.1. □ 

Claim 7.8 There exists a ( possibly empty) sequence a of steps of p and a step s of p such 
that the following Scenarios SI and S2 are possible. 

Scenario SI (scenario starts with O in state 5) 

1. Process p initiates and partially executes Apply (p,op,0) by completing the steps in a. 
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2. Process q initiates and completes (all the steps of) Apply (q, op', O), returning v' . 

3. p completes the remaining steps of Apply (p, op, O), returning v. 

Scenario S2 (scenario starts with O in state S) 

1. p initiates and (partially) executes Apply(p, op, C?) by completing the steps in a ■ s. 

2. q initiates and completes (all the steps of) Apply(g, op', O) , returning u' . 

3. p completes the remaining steps of Apply(p, op, O), returning u. 

Proof Clearly if process p executes no steps of Apply(p, op, O) before process q initiates and 
completes Apply(g, op', O), then Apply(g, op', O) must return v' . Further, if p initiates and 
completes all the steps of Apply(p, op, O) (let j3 be this sequence of steps) before q initiates 
and completes Apply(g, op', O), then Apply(g, op' , O) must return u' . Together with Claim 
7.7 by which Apply (g, op' , O) must return either u' or v', the above implies that there exists 
a sequence a of steps and a step s such that a.s is a prefix of j3 for which the claim holds. 
□ 

Hereafter we will assume Ok is the base object accessed by p in step s. 

Claim 7.9 Consider 

Scenario S3 (scenario starts with O in state S) 

1. p initiates and (partially) executes Apply(p, op, C?) by completing the steps in a.s. 

2. q initiates and completes (all the steps of) Apply(g, op', O), returning u' (as in S2). 

3. 0\, 02, ■ ■ ■ , O n fail by R-crash. 

4- p completes the remaining steps o/ Apply (p, op, (9). 

Then Apply (p,op f O) returns u. 

Proof Suppose Apply (p,op,0) returns X. Since J is gracefully degrading, O must either 
be correct or fail by R-crash. This requires, given that Apply (q, op', O) returns a non-X 
response, that Apply(g, op' , O) precede Apply(p, op, O) in the linearization order. Doing so, 
however, implies that (op' , u') is a sequential execution from S consistent with T. This is 
false since u' # v' , T is dete rminis tic, and (op 1 , v') is a sequential execution from S consistent 
with T. Thus Apply(p, op, O) cannot return X. 

Suppose Apply(p, op, O) returns w where X # w ^ u. Since in the linearization, ei- 
ther Apply(p, op, O) precedes Apply(g, op', O) or Apply(g, op', C?) precedes Apply (p,op,0), 
it follows that either (op, u;),(op', u') or (op 1 ,u'),(op,w) is a sequential execution from S con- 
sistent with T. This is false since (op, u),(op',u') and (op 1 ,v'),(op,v) are the only sequences 
consistent from the state S of T, and w ^ u, u' ^ v' . 

We conclude that Apply(p, op, O) must return u. □ 


38 


Claim 7.10 Consider 

Scenario S4 (scenario starts with O in state 5) 

1. p initiates and (partially) executes Apply {p,op,0) by completing the steps in a.s. 

2. Ok fails by R-crash. 

3. q initiates and completes (all the steps of) Apply (q, op', O). 

4 • O i, . . . , Ok-i and Ojfe-f-i, . . . , O n also fail by R-crash. 

5. p completes the remaining steps of Apply (p, op, O). 

Then Apply(p, op, O) returns u and Apply(g, op', O) returns u f . 

Proof Clearly S4^ p S3. Therefore, as in S3, Apply(p, op, O) returns u in S4. Since 1 is 1- 
tolerant, and since only Ok has failed by the completion of Apply(g, op', <9), Apply(g, op' , O) 
must return a non-_L response. From the definitions of u,u' ,v ,v' , it is easy to verify that 
the only non-J_ response that satisfies linearizability is u r . □ 

Claim 7.11 Consider 

Scenario S5 (scenario starts with O in state S) 

1. p initiates and partially executes Apply(p, op, O) by completing the steps in a. 

Ok fails by R-crash. 

3 . q initiates and completes (all the steps of) Apply (q,op',0). 

4 • 0 \, . . . , Ok-i and Ofc+i, . . . , O n also fail by R-crash. 

5. p completes the remaining steps of Apply (p, op, O) . 

Then Apply (p, op, O) returns u. 

Proof Clearly S5s= g S4. Therefore Apply(^, op', O) returns u' as in S4. By similar arguments 
as in Claim 7.9, it can be shown that Apply(p,op, O) returns u. □ 

Claim 7.12 Consider 

Scenario S6 (sceneirio starts with O in state S) 

1. p initiates and partially executes Apply (p,op,Q) by completing the steps in a. 

2. q initiates and completes (all the steps of) Apply(<j, op', O). 

3. All base objects 0\, O 2 , . . . , O n fail by R-crash. 
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4. p completes the remaining steps of Apply (p, op, O). 

Then Apply (p,op,0) returns u, and Apply (q, op' ,0) returns v' . 

Proof Since S6 S5, Apply(p, op, O) returns u as in S5. Since S6 SI, Apply(g, op', O) 
returns v' as in SI. ^ 

Neither (op,u),(op' ,v') nor (op 1 ,v'),{op,u) is a sequence consistent from the state 5 of 
T. Hence the execution in Claim 7.12 is not linearizable. Thus the failure of O in S6 is not 
by R-crash. We conclude that 1 is not a gracefully degrading implementation for R-crash, 
a contradiction which concludes the proof of Theorem 7.2. d 

The above discussion raises some questions on the “practicality” of the R-crash model: 
Even if “hardware” objects fail by R-crash, “software” objects usually don’t. The R- 
omission model defined in this paper does not have this serious limitation. In fact, for 
any t > 0, every N- process object type has a t-tolerant gracefully degrading implementation 
from any universal list of types. In other words, implementations preserving the R-omission 
semantics of the underlying system always exist. This is a formal justification for adopting 
the R-omission model of failure. These results are presented in the next section. 

7.2 R-omission 

The object type N-consensus is order-sensitive. By Theorem 7.2, N-consensus has no 
t-tolerant gracefully degrading implementation for R-crash. In contrast, N-consensus has 
such an implementation for R-omission (Theorem 5.2 in Section 5). Further, we can show 

Theorem 7.3 register has a t-tolerant gracefully degrading self-implementation for R- 
omission. 

Theorems 5.2 and 7.3 can be combined with the universal constructions in [Her91, JT92] 
to obtain the following result for R-omission. 

A list C of object types is N -universal if every IV-process object type has an implemen- 
tation from C. An example of a JV-universal list is (N-consensus with reset, register). 

Theorem 7.4 Every N -process object type has a t-tolerant gracefully degrading implemen- 
tation from any N -universal list of object types for R-omission. 


8 Related work 

In an independent work, Afek et al. consider the problem of coping with shared memory 
subject to memory failures [AGMT92]. Informally, each failure is modeled as a faulty write. 
The following failure models are considered: 
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A. There is a bound m on the total number of faulty writes. 

There is a bound f on the total number of data objects that may be affected by memory 
failures, and a bound k on the number of faulty writes on each faulty object. A 
different model is obtained for k — oo. 

In our terminology, these models are responsive. The second one, with k — oo, corresponds 
to our R-arbitrary failure model. 

[AGMT92] focuses on fault-tolerant implementations of the following types of ob- 
jects: safe, atomic, binary, and K-valued register from various types of registers; N- 
process test&set from iV-process test&set and bounded register; and N~consensus 
from read-modif y-write (RMW). [AGMT92] also gives a universal fault-tolerant imple- 
mentation from unbounded RMW, based on Herlihy’s universal implementation. The main 
differences between [AGMT92] and this paper are as follows: 

1. [AGMT92] does not consider any non-responsive failure model. 

2. Amongst the responsive failure models, benign ones, such as R-crash and R-omission, 
are also not considered in [AGMT92]. 

3. This paper does not consider models that bound the number of times faulty objects 
can fail (in [AGMT92] each “faulty write” is counted as a failure). 

4. The two approaches to modeling failures are fundamentally different. There is no 
direct way to model benign failures, such as R-crash and R-omission failures, with 

faulty writes . On the other hand, our approach — de finin g how each faulty object 
deviates from its type is not suited to handle Model A above. 

5. This paper introduces the concept of graceful degradation , and presents several related 
results, in particular, for R-crash and R-omission failure models. For R-arbitrary 
failures, graceful degradation reduces to the “ strong wait- freedom” concept considered 
in [AGMT92]. 

6. The concept of fault- tolerant self-implementation, is a central theme of this paper. 
Corollary 5.1 states sufficient conditions for their existence, and Corollary 5.2 lists 
several types that have such implementations. In the Open Problems section of 
[AGMT92] it is stated: 

It would be particularly interesting to implement memory-fault tolerant 
data objects directly from similar, faulty objects, such as test-and-set from 
test-and-set, without using atomic registers, or read-modify- write from read- 
modify-write, without using an unbounded universal construction.” 

It is interesting to note that both of these types do have fault-tolerant self- implementations. 
For bounded RMW, this is a direct consequence of Corollary 5.1. For TV-process test&set, 
one can combine the fault- tolerant implementation of test&set from test&set and 
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bounded register [AGMT92], with the implementation of bounded register from 
test&set [Jay93]. 

7. The existence of a fault-tolerant seZ/- implementation of consensus, shown in this 
paper, does not follow from the results in [AGMT92]. 

8. The fault-tolerant implementation of JV-process testftset from test&set and bounded 
register shown in [AGMT92], does not follow from our results (when N > 2). 
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A Formal model 


Our formal model is based on I/O Automata [LT88]. We use the model to make our 
definitions of failure models (Appendix B) and fault-tolerant implementations (Appendix 
C) precise. The implementations in the paper are described in the more intuitive Pascal-like 
style. In the following, we borrow several definitions from in [HW90, Her91]. There are 
however some differences between our model and Herlihy’s [Her91]. Notable among these 
are: (i) our addition of an explicit “crash” state for a process, (ii) the definitions of wait- 
freedom, and im plementation, (iii) the added assumption of fairness in our model, and (iv) 
the definition of clocked concurrent systems. 

A.l I/O Automata 

An I/O Automaton A is a non-deterministic automaton with the following components: 

1. States(A) is a finite/infinite set of states, including a distinguished set of starting 
states. 

2. In(A) is a set of input events. 

3. Out(A) is a set of output events. 

4. Int(A) is a set of interned events. 

5. Step(A) is a transition relation given by a set of tuples (s,e,s'), where s and s f are 
states, and e is an event. Such a triple is called a step, and it means that an automaton 
in state s can undergo a transition to state s r and that transition is associated with 
event e. 

If (s, e, s ; ) is a step, we say e is enabled in state s. I/O Automata (abbreviated hereafter 
as automata) must additionally satisfy the requirement that input, output, and internal 
events axe disjoint, and every input event is enabled in every state. 

An execution fragment of an automaton A is a finite sequence € i> 5 i, c 2> $2? • * * s n 
or an infinite sequence $0i € l> 5 i> e 2? $ 2 , • • • of alternating states and events such that ( , C j-j- 1 , Sj-f 1 ) 

is a step of A. An execution is an execution fragment in which so is a starting state. A 
history fragment of an automaton is the subsequence of events in an execution fragment of 
the automaton. A history of an automaton is the subsequence of events in an execution. An 
execution fragment E is fair if either E is finite, or E is infinite and every internal event or 
an output event that is enabled in every state of a suffix of E occurs infinitely many times 
in E. 14 

A new automaton can be constructed by composing a set of compatible automata. A 
set of automata are compatible if, no two of them share any internal or output events. That 

14 Since this simple notion of fairness is adequate for our purpose, we do not need the general machinery 
described in [LT88] for formulating fairness. 
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is, for every A, B in the set, (Int(A) U Out(A))D(Int(B) U Out(B))= 0. A state of the 
composed automaton 5 is a tuple of the components’ states, and a starting state of S is 
the tuple of the components’ starting states. The set of output events of S, Out(S), is the 
union of the sets of output events of the component automata. The set of internal events 
of 5, Int(S), is the union of the sets of internal events of the component automata. The 
set of input events of 5, In(S), is IN - Out(S), where IN is the union of the sets of input 
events of the component automata. A triple (s,e,s') is in Step(S) if and only if, for all 
the component automata A, one of the following holds: (1) e is an event of A, and the 
projection of the step onto A is in Step(A), or (2) e is not an event of A, and the state of 
A in s and s' is the same. 

If if is a history of a composed automaton and Ai, A 2 , . . . , Ak are component automata, 
then if |{Ai, A 2 , . . . , A*.} is the subhistory of if consisting of all events e, where e is an event 
of one of Ai, A 2 , . . . , A*. 

A. 2 Object type 

An object type T is a tuple (N, OP, RES, G), where N is an integer greater than one, OP, 
RES are sets of operations and responses respectively, and G is a directed finite or infinite 
graph in which each edge has a label of the form (op, res) where op £ OP and res £ RES. 
Intuitively, if O is an object of type T, then O supports the operations in OP and may be 
shared by N processes (we say T is an N -process type). G specifies the expected behavior 
of O in the absence of concurrent operations on G. 

The vertices of G are the states of T. One state of T is the initial state. A state s of 
T is reachable if there is a path in G from the initial state to s. We assume that every state 
of T is reachable. A sequence S = (opi,resi),(op 2 ,res 2 ), . . .,(opi,res\) is consistent from a 
state s of T if there is a path labeled S in G from the state s. S is consistent with respect 
to T if it is consistent from the initial state of T. 

An object type T is total if for every state s of T, and every operation op £ OP, there 
is a response res such that there is an edge labeled (op, res) from s in G. All object types 
studied in this paper are assumed to be total. T is deterministic if for every state s of 
T and every operation op £ OP, there is at most one edge from s labeled (op, res). T is 
non- deterministic otherwise. T is finite if G is finite; T is infinite otherwise. 

A.3 Processes and objects 

An object is an automaton with two attributes: a unique name and a type. A process is an 
automaton with a unique name. A process automaton P satisfies the following properties: 


1. There is a distinguished state CRASHED(P) in States(P). 

2. The event crash(P) is in In(P). 

3. For every state s £ States(P), (s,crash(P),CRASHED(P)) is in Steps(P). 
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4. The event crashed(P) is in Out(P), and is enabled in the state CRASHED(P). 

5. if ( CRASHED(P),e,s ) is in Steps(P), then either e = crashed(P), or e is an input 
event of P, and s = CRASHED(P) . 

The above conditions capture the notion that an adversary can crash a process at any 
time by generating the input event crash(P) (see 2 and 3); and once it crashes , a process 
remains crashed forever (see 5). 

A.4 Clock 

A clock is an automaton with a single state s, a single output event tick , and a single step 
(s,tick, s ). It has no input or internal events. 

A. 5 Concurrent system 

A concurrent system consisting of processes Pi, P 2 , . . . , P n , and objects Oi, O 2 , . • • , O m , is an 
automaton composed from process automata Pi, ... , P n , and object automata Oi, . . . , O m . 
We denote such a concurrent system by (Pi, P 2 , . . . , P n ; Oi, O 2 , . . . , O m ). A clocked concur- 
rent system 15 consisting of Pi, . . . , P n , and objects Oi, . . . , O m has an additional component, 
the clock automaton C, and is denoted by (Pi, . . . , P n ; Oi, . . . , O m \ C). The output events 
of a process P* include invoke(P{, op, Oj), where op is an operation supported by the type 
of Oj, and the input events of Pi include respond(Pi,res,Oj), where res is a response. 
We refer to the events invoke{P{, op, Oj) and respond(Pi,res,Oj) as invocations and re- 
sponses respectively. An object Oj includes input events invoke(P{, op, Oj), and output 
events respond(Pi,res,Oj). Process and object names are unique, an d no two automata 
among processes and objects share any internal or output events. This ensures that the 
process and object automata are compatible, and therefore, can be composed. 

Let a be a sequence of events or a sequence of states and events (for example, a can 
be a history or an execution). A response r matches an invocation i in <r if i is the latest 
event in a that precedes r such that the process and object names of i and r agree. An 
operation in a is a pair of events, an invocation and its matching response. A relation < a 
reflecting the partial “real time” order of operations in <<? is defined as follows: op < a op f 
if the response of op precedes the invocation of op f in < 7 . Two operations unrelated by <& 
fire said to be concurrent in cr. An invocation is pending in a if it has no matching response. 
Complete(a) denotes the maximal subsequence of <7 in which there is no pending invocation. 

A history H of a concurrent system S = (Pi, P 2 , . . . , P n ; Oi, 02, * • *1 O m ) is k-well- 
formed if, for each pair P{, Oj, (ff|Pi)|0 ; - begins with an invocation, and alternates invo- 
cations and matching responses 16 , and H\P{ has at most k pending invocations in H . The 

15 Clock ensures that the system execution progresses, no matter how the other components in the system 
behave. This simplifies the definition of wait-free implementations, especially wait-free implementations that 
must tolerate non-responsive failures. 

16 With the exception of the last invocation which may not have a matching response 
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concurrent system S is k- well- formed if every history of S is k- well- formed. Intuitively, in 
a fc-well-formed concurrent system, if an invocation of a process P on object O is pending, 
then P may not issue a new invocation on O; however, P may issue an invocation on a 
different object O f as long as the number of pending invocations from P does not exceed 
k. The need for a k- well-formed system, for k > 1, arises while designing implementations 
that tolerate non-responsive failures of the underlying objects. For example, it is easy to 
see that any implementation that has to be wait-free in spite of the crash of at most t un- 
derlying objects must be at least (t 4* 1)- well- formed. We assume that a concurrent system 
is 1- well- formed unless specifically mentioned otherwise. 

In this paper, we restrict our attention to only fair executions of concurrent systems. 
Thus, when we refer to infinite executions in this section and in Sections 3 and 4, we 
implicitly assume they are fair. 

A. 6 Linearizability 

The behavior of an object O in an execution E y denoted by B(G,E ), is the subsequence of 
invocation and response events of O in E , 

A behavior B is linearizable with respect to type T if B can be extended to B f by append- 
ing zero or more responses, and there is a sequence a = invoke(Pi 1 , op\ , 0), respond(P { l , resi, 0) y 
invoke(Pi 2y op 2y O) y respond(P i2 ,res 2 ,G) ) . . ., invoke(P in opi, O), respond(P in resi,0 ), such 
that: 

1 . <j is a permutation of the events in Complete^'). 

2 . <bQ<*. 

3. (opi,re$i), (op 2 , res 2 ), . . . , (op/,res/) is consistent with respect to T. 

Informally, extending B to B 1 captures the notion that some operations in B may 
have taken effect, although the responses have not appeared yet. The definition captures 
the notion that processes appear to interleave at the granularity of complete operations 
on O (as is evident from the form of a and Condition 1), the notion that this apparent 
interleaving respects the real time order (Condition 2) and the semantics of the object type 
T (Condition 3). 

An object O is linearizable with respect to type T in a finite execution E of a concurrent 
system if B(0,E) is linearizable with respect to T. 

Object O is linearizable with respect to type T in an infinite execution E of a concurrent 
system if and only if it is linearizable with respect to T in every finite prefix of E. 

A. 7 Wait-freedom 

Let E be an execution of a concurrent system. An object O is wait-free in E if either (i) E 
is finite, or (ii) every invocation on O by a process that does not crash in E has a matching 
response. 
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A. 8 Correctness 


An object O is correct in an execution E if one of the following holds: 

• O is is wait-free in ft and O is linearizable with respect to its type in E. 

• More than N (T) distinct processes have invocations on O in E. 

The latter condition captures the notion that an object need not exhibit any sane 
behavior if accessed by more processes than the object is intended for. 

An object O fails in an execution E if it is not correct in E. 

A • 9 Implement at ions 

Let Obj(T) denote the universe of objects whose type is T. Let C = (Ti, T 2 , . . . , T n ) be a list 
of object types (TVs are not necessarily distinct). A wait-free implementation ofT from £ 
for processes Pi, ft, , Pjv(T) is a function X : Obj(Ti) x Obj(T 2 ) x . . . Obj(T n ) — ► Obj(T) 
satisfying the following conditions: 

1. If 0 = J(Oi> 02, . . . , 0 n ), the automaton of O has the structure of a concurrent sys- 
tem: (Pi, ft, . . . , P/v(j); 0i, O 2 , • • • , O n ), for some process automata ft, ft, . . . , ftv(T)* 

2. ft and Fj ( i ^ j) have no common events. 

3. If O — T(0i, . . . , 0 n ), each input event invoke{P{,op , O) of O is an input event of ft; 
each output event respond(Pi,res, O ) of O is an output event of ft. 

4. Each output event crashed(P { ) of Pi is matched with the input event crash(Fi) of ft. 

5. Let Oi, O 2 , * . . , O n be any distinct objects of type Ti,T 2 , . . . , T n , respectively, and O = 

J(Ox, . . . , O n ). For every execution E of the clocked concurrent system (Pi, P 2 , • • • , Pn(T )j O; C), 
if Oi, 0 2 , . . . , O n axe correct in E , then O is also correct in E. 

In the above, the ftfs axe called the front-ends , O = P(Oi, 0 2 , • . . , O n ) is called a 
derived object of the implementation J, and Oi, 0 2 , . . . , O n axe called the base objects of O. 

The front-end F{ models the procedure Apply (called by process P t to execute operations 
on a derived object) alluded to in the informal model of Section 2. 

Condition 1 states that a derived object is constituted by base objects and access 
procedures (front-ends). 

Condition 2 captures the notion that the execution of a step of the implementation by 
one process P{ cannot affect another process Pj. 

Condition 3 captures the notion that (i) invoking an operation on 0, by process Pj 
causes the front-end Fi to be activated, and (ii) the value returned by the front-end Fi is 
the response of O. 
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Condition 4 condition captures our intuition that when a process P{ crashes, the front 
end F{ of that process must stop executing. 

Condition 5 ensures that a derived object behaves correctly when its base objects do. 

All implementations studied in this paper are wait-free. Hereafter we write “imple- 
mentation” as shorthand for “wait-free implementation”. The implementation 1 is a self- 
implementation if Ti = T<i — . . . = T n = T. The resource complexity of 1 is n, the number 
of base objects that make up a derived object of the implementation. 


B Models of failure 


Failure models for objects were explained in Section 3 using the informal terminology of 
Section 2. We present here the formal definitions of these failure models based on the formal 
model developed in Appendix A. 

The failure models fall into two broad classes: responsive and non-responsive. As we 
will see, in most models of failure, an object O of type T that fails may return a response 
that is not in RES{T). When a process P gets such a response from C?, it knows that O is 
faulty. Thus, it is reasonable to assume that P does not invoke operations on O thereafter. 
We restrict our attention to executions in which this assumption holds. 

B.l Responsive models of failure 

Responsive failure models share the following property: even an object that fails in an 
execution E , is wait-free in E. 


B.1.1 R-crash 

An object O fails by R-crash in an execution E of a concurrent system iff it fails in E , and 
the following hold in E: 

1. O is wait-free. 

2. Every response from O either belongs to RES(T) or is 1 (where 1 is a distinguished 
value not in RES(T ), T being the type of O). 

3. If op < E op' and the response for op is ±, then the response for op' is also ±. This is 
the “once _L, everafter J_” property of R-crash. 

4. Recall B(0 , E ), the behavior of O in E . Let B f be obtained by removing all operations 17 
in B(0,E) whose responses are 1. B f is linearizable with respect to the type of O. 
This property captures the notion that an object failing by R-crash behaves correctly 
until it fails. 

17 Removing an operation involves removing the invocation and the response of that operation. 
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B.1.2 R-omission 


An informal motivation for this model can be found in Section 3.1.2, and a formal justifi- 
cation in Section 7. 

An object O fails by R-omission in an execution E of a concurrent system iff it fails in 
E, and the following hold in E: 

1. O is wait-free. 

2. Every response from O either belongs to RES(T) or is i. (where _L is a distinguished 
value not in RES{T), T being the type of O). 

3. Let B' be obtained from B(0,E) by removing all response events that get J_. Then 
B' is linearizable with respect to the type of O. 

Property 3 captures the notion that a failed operation of P appears like an incomplete 
operation. Also notice the subtle difference in the way we obtain B' from B(0,E) for R- 
crash and for R-omission. We urge the reader to understand its implications on the failure 
semantics of the two models. 


B.1.3 R-arbitrary 

An object fails by R-arbitrary in an execution E of a concurrent system iff it fails in E, and 
is wait-free in E. 

B.2 Non-responsive models of failure 

Each responsive model of failure has its non-responsive counter-part. The difference is that, 
with non-responsive failures, an object that fails in an execution E may not be wait-free in 

E. 

B.2.1 Crash 

An object O fails by crash in an execution E of a concurrent system iff it fails in E, and 
the following hold in E: 

1. B(0,E) is linearizable with respect to the type of O. 

2. The total number of responses from O in E is finite. 

Property 2 captures the notion that an object that fails by crash does so at some finite 
point in the execution. Hence the number of times it will have responded in that execution 
must be finite. 
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B.2.2 Omission 


An object 0 fails by omission in an execution E of a concurrent system iff it fails in E , and 
B(O^E) is linearizable with respect to the type of Q. 

B.2.3 Arbitrary 

An object O fails by arbitrary in an execution E of a concurrent system iff it fails in E . 


C Definition of fault-tolerant implementations 


An implementation I of type T for processes P \ , P 2 , . . . , -P/v(T) is t -tolerant for failure model 
M if every derived object O of I has the following property: In every execution of the 
clocked concurrent system (Pi,P 2 , • • • ,Pn(T)\ 0;C), if at most t base objects of O fail, and 
they fail by M, then O is correct. 

An implementation 1 of type T for processes Pi,P 2 , ■ . • , Pn(T) is gracefully degrading 
for failure model M if every derived object O of I has the following property: In every 
execution of the clocked concurrent system (Pi, _P 2 , • • • , Pn(T)\ O; C), if all base objects of 
O that fail, fail by M, then either O is correct or it fails by Ai. 


D Type definitions 

Recall that an object type T is defined (Section 2) as a tuple (N, OP, RES, G), where N 
is the number of processes supported by an object O of type T, OP is a set of operations 
supported by O, RES is a set of result values, and G is a graph giving the sequential 
specification of O. In this appendix, we specify OP, RES and G for most object types that 
occur in the paper. The parameter N is unspecified: each choice of N results in a different 
type. Similarly, in most cases, the initial state of G is not specified. A new type results for 
each choice of an initial state. 
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OP = {compare&;swap(t;i, 1 * 2 ) ki, v 2 booleans} 
RES = {0, 1} 

Object State: 

X, a boolean 

compare&swap^i, v 2 ) 
if X = v\ then 
X := v 2 
return(X) 


Figure 8: Compare&svap 


OP = {reset()} U (propose^) |v G {0, 1}} 
ii£?5 = {0, 1, ack} 

Object State: 

X € {0,1, X}, initially X 

propose(u) 

if X = X then 
X := v 
return (X) 

reset() 

X := X 
return (ack) 


Figure 9: Consensus-with-reset 
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OP = {f etch&add( , i;)|i; is an integer} 
RES = Set of integers 
Object State: 

X, an integer 

f etch&add(t?) 

X := X + v 
return (X) 


Figure 10: Fetch&add 


OP = (enq(tr)|i> is integer} U {deq()} 
RES = {v| v is integer} U {nil, ack} 
Object State: 

X, a sequence of integers 

enq('u) 

X := X • v 
Tetum(ack) 

deq() 

if X is empty then 
return(m/) 

else if X = v * X f then 
X := X r 
retum(v) 


Figure 11: Queue 



OP = {read(i),write(v,i),move(i)|v,i G {0,1}} 
RES = {0,1, ack} 

Object State: 

Xo,Xi€{0,l} 

read(i) 

if i = 0 then 
return(Xo) 
else return(Xi) 

write(v, i) 

if i = 0 then 

X 0 

else X\ := v 
return (ack) 

move(i) 

X 1 := 

return (ack) 


Figure 12: Move 


OP = {write(t/)| v is integer} U {read()} 
RES = {v\ v is integer} U {ack} 

Object State: 

X , an integer 

read() 

retum(-X’) 

write(v) 

X := v 
return (ack) 


Figure 13: (Unbounded) Register 
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OP = {push(v)|v is integer} U (pop()} 
RES = {v| t/ is integer} U {nil, ack} 
Object State: 

X, a sequence of integers 

push(r) 

X := X -v 
ret\ivn(ack) 

pop0 

if X is empty then 
return(nz/) 

else if X = X 1 • v then 
X := X' 
return(v) 


Figure 14: Stack 


OP = {write(v)|v 6 {0, 1}} U (read()} 
iZ2?5 = {0, 1, ack} 

Object State: 

X € {0,1, J_}, initially J_ 

read() 

retum(X) 

write(v) 

if X = J_ then 
X :=v 
return(aci) 


Figure 15: Sticky-bit 



OP = {read(i), write(v, i), swap()|v, i € {0,1}}} 
RES = {0, 1 ,ack} 

Object State: 

JTo,*i€{0,l} 


read(i) 

if i = 0 then 
return (Xo) 
else return(JCi) 

write(u, i) 

if i = 0 then 
X 0 :=v 
else X\ := v 
return (ack) 

swap() 

temp — Xo 
X 0 := X 1 
X\ := temp 
retum(acA:) 


Figure 16: Swap 
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OP = {test&setQ, reset()} 
RES = {0, 1, ack} 

Object State: 

*€{ 0 , 1 } 

test&set () 

y :=* 

X :=0 
retum(2/) 

reset() 

X := 1 
retum(acA:) 


Figure 17: Test&set 




